openclaw - 💡(How to fix) Fix Support MCP `notifications/tools/list_changed` in the client + add an HTTP reload endpoint for `mcp.servers.*` [1 pull requests]

Context

We operate OpenClaw at scale at Pareto Colabs — each customer hire runs a dedicated OpenClaw worker on Railway, and we expose Composio as an MCP server so the agent can use customer-connected integrations (GitHub, Linear, Notion, etc.).

The customer journey is: hire is provisioned → customer connects a new integration in our UI → our backend calls Composio API to create the connection → agent should immediately see the new tools.

In practice the agent only sees new tools after the MCP runtime is disposed and recreated — which today happens only on mcp.sessionIdleTtlMs (default ~10min) or on a config change. For an enterprise product this is a poor UX (customer connects GitHub, agent says "I don't have GitHub tools yet, try again in 10 minutes").

What I found in the source

After digging through the bundled gateway in dist/:

1. The bundled @modelcontextprotocol/sdk defines notifications/tools/list_changed in the schema (types.js), but the gateway's MCP client wrapper never calls setNotificationHandler for it. The catalog is cached in getCatalog() until the runtime is disposed.

2. There is no HTTP endpoint to reload a specific MCP server. The WS RPC config.set exists but is operator-scoped, and the CLI openclaw config set requires a shell inside the container — neither works from an external backend after an OAuth callback.

3. There is no system.config_set core tool in CORE_TOOL_DEFINITIONS, so we cannot use /tools/invoke either.

What I'd love to see

Ideally both, in priority order:

A. (Spec-correct) Handle notifications/tools/list_changed in the MCP client

When the bundled MCP client receives this notification from a server, invalidate the catalog cache and re-fetch on next access. This is the canonical MCP-spec way and zero glue is needed for downstream consumers.

Servers that emit the notification (when their tool list changes — e.g. user connects a new integration) would Just Work.

B. (Pragmatic) Authenticated HTTP endpoint POST /api/mcp/servers/:id/reload

Authenticated with the same bearer used by /tools/invoke. Disposes the MCP runtime for that server in the current session(s) so the next turn re-fetches. Useful when the upstream MCP server doesn't emit the notification (today, Composio's MCP servers don't, based on our investigation — see ComposioHQ/composio#3118).

A core tool system.mcp_reload exposed via /tools/invoke would also work for us and follows the same pattern as whatsapp_login already does in the WhatsApp plugin.

Why this matters

We currently run a banner in our UI telling customers "your integration might take up to 10 minutes to appear" — which signals lack of maturity for an enterprise product. Either A or B unlocks a clean OAuth callback → reload → new tools available end-to-end.

Happy to send a PR if maintainers agree on the shape — drop a note on which surface you'd prefer (notification handler vs HTTP endpoint vs core tool) and I'll open one.

— Vilfredo / Pareto Colabs