Problem
The spec requires servers to return serverInfo.name (and optionally serverInfo.title) in the initialize response, but is silent on how clients should expose that name to the model. In practice, several hosts fall back to opaque identifiers (UUIDs) when a server is registered via a hosted "connector" UI rather than a local config file.
Concrete example in Claude Code: MCPs added via the claude.ai connector UI surface to the model as mcp__<uuid>__<tool>:
mcp__5fc0702b-3e50-48aa-9d6a-b6f40e57935e__search_knowledge
mcp__6155d1e3-80db-4b42-9c1c-c060bc2f2d48__mcp-adapter-discover-abilities
mcp__da661240-977b-4550-a00f-5c1295d3014b__gcal_list_events
The model has no way to tell these apart without probing each one (e.g. calling list_my_clients or discover_abilities) to work out what it's actually talking to. The display name the user configured in the connector UI is never surfaced.
Why this is a spec-level concern, not a per-client bug
Tracked for Claude Code specifically in anthropics/claude-code#47614, but the same failure mode will recur in any client that distinguishes between "locally configured" and "hosted connector" MCPs. Without spec guidance, each host invents its own conventions and the ecosystem fragments — an MCP author can't predict how their server's name will be rendered to the model across clients, and users end up with namespaces like mcp__<uuid>__<tool> that defeat the purpose of having named connectors in the UI at all.
Suggested direction
Add guidance (or a normative requirement) that clients MUST make serverInfo.name / serverInfo.title (or a user-configured alias) discoverable to the model, either:
- As part of the tool namespace prefix (preferred — matches current conventions), or
- In tool descriptions / an introspection primitive the model can call
Tool-prefix schemes that use opaque IDs visible to the model should be explicitly discouraged. The server already tells the client its name during initialization; nothing in the protocol prevents the client from honouring it.
Related
Problem
The spec requires servers to return
serverInfo.name(and optionallyserverInfo.title) in theinitializeresponse, but is silent on how clients should expose that name to the model. In practice, several hosts fall back to opaque identifiers (UUIDs) when a server is registered via a hosted "connector" UI rather than a local config file.Concrete example in Claude Code: MCPs added via the claude.ai connector UI surface to the model as
mcp__<uuid>__<tool>:The model has no way to tell these apart without probing each one (e.g. calling
list_my_clientsordiscover_abilities) to work out what it's actually talking to. The display name the user configured in the connector UI is never surfaced.Why this is a spec-level concern, not a per-client bug
Tracked for Claude Code specifically in anthropics/claude-code#47614, but the same failure mode will recur in any client that distinguishes between "locally configured" and "hosted connector" MCPs. Without spec guidance, each host invents its own conventions and the ecosystem fragments — an MCP author can't predict how their server's name will be rendered to the model across clients, and users end up with namespaces like
mcp__<uuid>__<tool>that defeat the purpose of having named connectors in the UI at all.Suggested direction
Add guidance (or a normative requirement) that clients MUST make
serverInfo.name/serverInfo.title(or a user-configured alias) discoverable to the model, either:Tool-prefix schemes that use opaque IDs visible to the model should be explicitly discouraged. The server already tells the client its name during initialization; nothing in the protocol prevents the client from honouring it.
Related