When MCP servers drift, user settings may stop applying to the capability you meant

Loocor · reddit · 2026-07-30

When MCP servers drift, user settings may no longer map cleanly

This post argues that the new MCP 2026-07-28 spec still leaves an important operational problem unsolved: if a server’s tools keep changing, how should a client preserve a user’s long-lived intent about a capability they previously allowed, denied, or selected?

The authors describe two concepts:

They say a single capability name is not enough to determine whether the same thing is still present, whether its definition changed, or which version should be exposed to which consumer.

Example from MCPMate

MCPMate is a desktop gateway that connects to multiple MCP servers and exposes tools, prompts, resources, and templates while letting users control what gets loaded. The post uses it to show how a client might need to track capability identity across server evolution.

Concrete case: Exa MCP Server

The authors examined public histories of eight open-source MCP servers over roughly a year and found the clearest example in Exa’s MCP server. At one pinned revision, the server registered ten tools by default; later PRs and changes caused some tools to disappear, reappear, or otherwise drift.

The main takeaway is that products which promise persistent per-capability settings need something more robust than tool names if they want to survive independent server evolution.

Original post →

More from coding & agent

coding & agent channel →