Gateway not reflecting READY:FALSE on registrations?

[matzew]

I noticed that when removing an MCP Server, the MCPServerRegistration goes to ready:false (correclty), but connecting to the gateway still lists the old tools ?

Steps to reproduce:

1. Install the GW (on OCP): https://github.com/Kuadrant/mcp-gateway/blob/main/config/openshift/deploy_openshift.sh

2. Install Operator: https://raw.githubusercontent.com/matzew/kubernetes-mcp-lifecycle-operator/refs/heads/distribution/dist/install.yaml

3. Create Kubernetes MCP Server resource: https://raw.githubusercontent.com/kubernetes-sigs/mcp-lifecycle-operator/refs/heads/main/examples/kubernetes-mcp-server/mcpserver-with-rbac.yaml

4. Create Gateway regsitration for the Server: https://raw.githubusercontent.com/matzew/kubernetes-mcp-lifecycle-operator/refs/heads/gateway_integration/examples/kubernetes-mcp-server/mcp-gateway/mcp-gateway-integration.yaml

Eventually this gives you:

kubectl get mcpserverregistrations -A                                                                                          fedora: Wed Mar 18 09:39:01 2026

NAMESPACE   NAME                    PREFIX   TARGET           PATH   READY   TOOLS   CREDENTIALS   AGE
default     kubernetes-mcp-server   kube_    kubernetes-mcp   /mcp   True    14                    7s

No, when deleting just the MCP Server (not the mcpserverregistrations), it goes to:

kubectl get mcpserverregistrations -A                                                                                          fedora: Wed Mar 18 10:42:24 2026

NAMESPACE   NAME                    PREFIX   TARGET           PATH   READY   TOOLS   CREDENTIALS   AGE
default     kubernetes-mcp-server   kube_    kubernetes-mcp   /mcp   False                         3m49s

But the tools are still visible on the MCP Inspector

[matzew]

I noticed also "stale" tools, when changing the configuration/image of the server. E.g. consider this config, with "admin" rights and more tools

---
# ServiceAccount for the kubernetes-mcp-server with admin access
apiVersion: v1
kind: ServiceAccount
metadata:
  name: mcp-admin
  namespace: default
---
# ClusterRoleBinding to grant full admin access across the cluster
# Uses the built-in 'cluster-admin' ClusterRole which provides
# unrestricted access to all resources
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: mcp-admin-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin  # Built-in ClusterRole with full permissions
subjects:
  - kind: ServiceAccount
    name: mcp-admin
    namespace: default
---
# ConfigMap containing the kubernetes-mcp-server configuration
apiVersion: v1
kind: ConfigMap
metadata:
  name: kubernetes-mcp-server-config
  namespace: default
data:
  config.toml: |
    # Kubernetes MCP Server Configuration
    log_level = 5
    port = "8080"
    read_only = false
    toolsets = ["core", "config"]
---
# MCPServer resource with ServiceAccount for full admin RBAC access
apiVersion: mcp.x-k8s.io/v1alpha1
kind: MCPServer
metadata:
  name: kubernetes-mcp-server
  namespace: default
spec:
  image: quay.io/container/kubernetes_mcp_server:latest
  port: 8080
  serviceAccountName: mcp-admin  # Use the ServiceAccount with cluster-admin permissions
  configMapRef:
    name: kubernetes-mcp-server-config
  args:
    - --config
    - /etc/mcp-config/config.toml

Applying it like:

oc apply -f ~/mcpserver-with-admin-rbac.yaml

serviceaccount/mcp-admin created
clusterrolebinding.rbac.authorization.k8s.io/mcp-admin-binding created
configmap/kubernetes-mcp-server-config configured
mcpserver.mcp.x-k8s.io/kubernetes-mcp-server configured

But instead of listing 20 tools, as expected, I have 14, still

[jasonmadigan]

Odd, we've an e2e test that covers this area pretty thoroughly. I'll take a look and see if I can reproduce.

My guess is MCP inspector not handling/seeing the tools/list_changed notification (should be able to see in logs). kubelet sync frequency may also be at play - after about 60s (IIRC the default sync frequency) did you reconnect and also see a stale list?

[jasonmadigan]

OK, I am seeing similar locally:

• gateway removes tools correctly, after kubelet sync frequency (60s)
• issues a notifications/tools/list_changed (see in server notifications)
• MCP Inspector does not currently actually do a tool list after receiving this event, users have to clear/list again to get an fresh list (has been an annoying UX quirk for a while now). Looks like this may be addressed at some point in Proposal: support tools/list_changed notifications handling modelcontextprotocol/inspector#832 / feat: handle tools/resources/prompts list_changed notifications modelcontextprotocol/inspector#1132

So I reckon you're seeing two things: 60s sync frequency & MCP inspector "quirks"

[matzew]

@jasonmadigan perhaps I should break this into to issues? the second comment is about the stale tools. Not related to the inspector - thanks for the pointers. Looks like will be "fixed" soon.

But what about this: #665 (comment) ?

[jasonmadigan]

yeah might be no harm to shift the 2nd comment into a standalone issue. I've only looked at the first bit.

[matzew]

Ok, cool - will do

[jasonmadigan]

Re: #665 (comment) - I see tool list events after 60s, and clear/list does show the new tools, but I noticed (like you) that the mcpserverregistration tool count remains stuck at 13. That looks like a bug to me.

[matzew]

@jasonmadigan moved it to #666 😅

I guess since the original issue here is already addressed by the inspector, I guess we can close this. IMO no need to keep it up

[jasonmadigan]

Sounds good - can tackle that bug with #666 (ominous!)