MCP connector tool list not refreshing after new tools added to server — cached tool list persists despite disconnect/reconnect

[dev-allserve]

MCP server URL

https://platform-tools.allserve-pl.au/mcp

Where does the issue occur?

When pressing the Connect button

Transport used

streamable-http

Client registration type

Dynamic Client Registration (DCR)

SSE only: Does your server return the expected status code for POST requests?

Not applicable (my server does not use SSE)

When did you last reproduce this?

Today, April 3 2026, approximately 09:18 AEST (your local time in Melbourne/Gold Coast).

Browser and OS

No response

Describe the issue

After adding a new tool (wp_push_jsonld) to an MCP server and rebuilding/restarting, the Claude.ai connector continues to show the old tool list (9 tools) and does not include the new tool. This persists after: disconnecting and reconnecting the connector, deleting and re-adding the connector at the org level, restarting the MCP server, renaming the tool to force cache invalidation. The server correctly registers the tool — verified via dist file inspection and PM2 logs. The tool list appears to be cached at the Claude.ai platform level with no mechanism to force a refresh. Expected behaviour: reconnecting a connector should fetch a fresh tool list from the server.

Issue details

Server: custom OAuth 2.1 MCP server using streamable-http transport
Tool added: wp_push_jsonld
Steps taken to force refresh:
1. Disconnected and reconnected connector in project settings
2. Deleted connector at org level and re-added with same URL
3. Restarted MCP server (PM2)
4. Renamed tool from wp_push_jsonld to wp_push_schema to force cache invalidation — still not visible
5. Rebuilt entire dist directory from scratch

Server-side verification confirms tool is registered:
- dist/tools/push-jsonld.js exists and contains correct tool name
- dist/index.js imports and calls registerPushJsonLdTool
- Tool count on server is 10, Claude.ai consistently shows 9

Expected behavior

When a connector is disconnected and reconnected, or deleted and re-added, Claude.ai should fetch a fresh tool list from the MCP server rather than serving a cached version. New tools added to the server should be visible in the next session after reconnecting.****

Logs from your server

Additional context

Additional context:

• MCP server uses OAuth 2.1 with dynamic client registration
• Server URL: https://platform-tools.allserve-pl.au/mcp
• Transport: streamable-http
• Claude.ai plan: Team (org level access confirmed)
• The 9 existing tools all work correctly — this is purely a tool list refresh/cache issue
• The new tool endpoint works correctly when called directly via curl with a valid Bearer token
• This is blocking a production publishing pipeline that depends on wp_push_jsonld for structured data injection

[localden]

Thank you for taking the time to report this and for the thorough diagnostic work — it's genuinely useful. We're currently triaging open MCP issues, and this one is being closed in favor of tracking it in #45, which covers the same problem (Claude's model-facing tool catalog not refreshing after the server's tool list changes) and is already labeled as a known issue on our backlog.

We're carrying forward the new evidence from these reports into #45 — in particular that the stale catalog survives disconnect/reconnect, org-level delete-and-re-add, and full OAuth re-consent, and can persist 24h+ (past the cache TTL discussed in #45), and that the connector settings UI can show the updated tool list while the model still sees the old one. Please follow #45 for updates and add any additional detail there.

[mysticaltech]

I'm having the same issue between, the icon is not showing.

[gilmarfavarin-ux]

Reproducing this on remote Custom Connectors (Streamable HTTP MCP) as a server developer, same root cause.

Setup: A remote MCP server behind an OAuth Custom Connector. Tools are registered per MCP session (at initialize); the tool list only changes between server deploys (new container image), never within a live MCP session.

Symptom: After a deploy that changes the tool list (added a tool / changed an argument enum), an already-open conversation keeps seeing the old tool list. Only a brand-new conversation picks up the updated list. It genuinely looked like the change "didn't ship," when in fact the new image was live and working — the client was serving a per-conversation cached tools/list.

Doesn't help: disconnect/reconnect, delete + re-add the connector, restarting the server. The cache is above the MCP-session layer.

What would fix it: honor notifications/tools/list_changed to re-fetch tools/list mid-conversation, and/or a working "refresh tools" action that actually re-queries the server. Right now the only reliable workaround is starting a new conversation after each deploy, which breaks iterative server development and any deploy-frequent workflow.

Happy to provide server-side logs (the MCP session re-initializes correctly on the server; it's the client-side tool list that stays cached).

[mxdilo]

Server-side workaround: meta-tools list_tools + call_tool

We ran into this same issue building a production MCP server
(Supabase Edge Functions + OAuth 2.1). While waiting for a
platform-side fix, we implemented a server-side workaround
that fully bypasses the caching problem.

Approach

Add two meta-tools to your MCP server:

1. list_tools — returns the real-time tool list directly
from the server, bypassing the client cache entirely.

2. call_tool(tool_name, tool_params) — dynamically routes
to any tool by name, even if it wasn't in the client's cached
tool list at session start.

How it works

// In your MCP gateway tools/call handler:

case 'list_tools':
  return successResponse({
    tools: TOOLS_LIST.map(t => ({
      name: t.name,
      description: t.description,
      parameters: Object.keys(t.inputSchema?.properties || {})
    })),
    _meta: getServerMeta()  // includes tools_hash
  })

case 'call_tool': {
  const { tool_name, tool_params } = input
  // Validate tool_name against known tools (security)
  if (!TOOL_ENDPOINTS[tool_name]) {
    return errorResponse('tool_not_found', 
      `Tool '${tool_name}' not found. Call list_tools first.`)
  }
  // Route to the actual Edge Function
  return await callTool(tool_name, tool_params)
}

Combined with hash-based change detection

Every tool response includes _meta.tools_hash
(a hash of the current tool names). The system prompt
instructs Claude to:

1. Store tools_hash as SESSION_TOOLS_HASH
2. On every tool response, compare _meta.tools_hash
   with SESSION_TOOLS_HASH
3. If different → call list_tools automatically
4. If a needed tool is in list_tools but not in direct tools
   → call it via call_tool
5. Transparent to the user — no manual refresh needed

Result

New tools added to the server are available in the
current session within one tool call, without any user
action, reconnect, or new conversation.

Limitations

• Requires Claude to follow system prompt instructions
  (works well with Claude Sonnet 4.x)
• call_tool adds one extra HTTP hop vs direct tool calls
• Does not fix the underlying caching issue — this is
  a server-side mitigation

Happy to share more implementation details if useful.
Would love to see a proper notifications/tools/list_changed
implementation on the client side eventually.

[jwk1230]

I'm observing the same issue here with Gainsight CS connector to their MCP Server.

When tools on the server side are enabled/disabled, the tool set on Claude side is unaffected even after refreshing the tools list on the Claude side and a session disconnect/reconnect

I would expect that if the tool is disabled on the server side, Claude shouldn't even know anything about it. But it seems like the configuration is cached somehow in a way that cannot be cleared by refreshing the tools list

Example: