MCP tool namespaces are opaque and inconsistent — cannot tell which server a tool belongs to

Thanks for the report. In Claude Code, MCP tools are namespaced by the server's name: mcp__<server-name>__<tool> for servers you configure, and mcp__claude_ai_<connector-name>__<tool> for claude.ai connectors, so the owning server is readable from the tool name. /mcp also lists each server with its URL or command. Docs: https://code.claude.com/docs/en/mcp

The UUID-style namespaces you saw don't come from Claude Code; if that was in the Claude Desktop app, please report it through Desktop's feedback channel. Closing here, but reopen if you can reproduce UUID names in a Claude Code CLI session.

🤖 Generated with Claude Code

Caveat up front: this is the Cowork tab, not the CLI. I can't reproduce UUID namespaces in a claude CLI session, so by the letter of the close condition this stays closed. But I'd ask you to reconsider the routing to "Desktop's feedback channel", because your own comment supplies the sharpest version of the bug.

You wrote that claude.ai connectors surface as mcp__claude_ai_<connector-name>__<tool>. In a Cowork session those same claude.ai-synced connectors surface as raw UUIDs. Per the Desktop docs, the Cowork tab "sources its skills, plugins, and connectors from this Customize configuration, which syncs through your claude.ai account" (docs) — so this is the same connector set your convention already covers, rendered two different ways depending on the tab.

Verbatim from one Cowork session on 2026-08-19, three namespace styles at once:

mcp__363d8e44-a135-481a-bb27-435b3a7fc461__ask_question              # UUID
mcp__582ccd2c-274a-4e6b-9576-085d8be31452__query-docs                # UUID
mcp__3679caf7-f0b1-409a-82f1-7ca4f46132b8__searchAppleDocumentation  # UUID
mcp__a8219592-a8fb-4731-80c7-559371fa179f__search_generic_code       # UUID
mcp__6f616b42-0ed8-571e-823f-ee4aca6b7ce9__show_widget               # UUID

mcp__DeepWiki__deepwiki_ask                                          # slug
mcp__deepwiki-mcp__deepwiki_ask                                      # slug
mcp__visualize__show_widget                                          # slug
mcp__computer-use__screenshot                                        # slug

mcp__plugin_pdf-viewer_pdf__display_pdf                              # documented plugin form

Four things here go beyond what I originally filed.

1. The same tool pair appears under both a slug and a UUID, simultaneously. mcp__visualize__read_me / mcp__visualize__show_widget were live in the tool list while mcp__6f616b42-…__read_me / mcp__6f616b42-…__show_widget were announced as newly available. Identical tool names, two namespaces, one session.

2. The server-instructions block identifies servers by UUID too. The section whose job is to give a server human-readable identity headed two of them as literally ## 363d8e44-a135-481a-bb27-435b3a7fc461 and ## 582ccd2c-274a-4e6b-9576-085d8be31452. There is no second surface that recovers the name.

3. Nothing can resolve a UUID back to a server. The installed-connector listing returned an empty set while those UUID-namespaced servers were actively exposing tools. So neither the user nor the model can answer "what is 363d8e44?"

4. The identifier is not stable within one conversation. Mid-session, mcp__363d8e44-…__*, mcp__582ccd2c-…__* and mcp__DeepWiki__* were reported as disconnected while mcp__deepwiki-mcp__* and mcp__6f616b42-…__* appeared. Surfacing late-connecting servers mid-turn is documented and fine; the problem is that the notice names the departing server by UUID, so "which server did I just lose?" is unanswerable.

The original confusion also still reproduces: server 363d8e44-… opens its instructions with "DeepWiki MCP provides AI-powered documentation for GitHub repositories" while its tool surface is Devin's (devin_session_create, devin_playbook_manage, list_integrations). Name says DeepWiki, capabilities say Devin, namespace says nothing.

I've also submitted this session through Desktop feedback, which attaches the transcript. The tool names above appear in it verbatim, so you don't have to take my transcription for it.

Concrete ask, scoped small: apply the convention you already described — mcp__claude_ai_<connector-name>__<tool> — to the Cowork tab, so one connector has one name across surfaces. That isn't a redesign, it's making Cowork match Claude Code.

Happy to move this to the Desktop channel if you'd still rather. My only worry is that the fix lives in a naming rule Claude Code owns, and splitting it across two trackers leaves the two halves of one convention to be fixed by different people.

It also reproduces in Claude Code, not only in Cowork. This isn't the terminal CLI, so it still isn't the reproduction your close condition names, and I'm leaving that call with you. But it is a Claude Code session — the Code tab of the desktop app, Claude Code 2.1.266 in Claude desktop 1.52386.3, today (2026-09-14) — and my claude.ai connectors are namespaced by connector UUID there, not as mcp__claude_ai_<connector-name>__<tool>:

mcp__3679caf7-f0b1-409a-82f1-7ca4f46132b8__searchAppleDocumentation  # connector "sosumi"
mcp__a8219592-a8fb-4731-80c7-559371fa179f__search_generic_code       # connector "GitDocsMCP"
mcp__6f616b42-0ed8-571e-823f-ee4aca6b7ce9__show_widget               # connector "visualize"
mcp__visualize__show_widget                                          # same tool, slug form, same session

All four names appear character for character in my Cowork list above, so the UUID is the connector's own id, stable across tabs. One difference from that Cowork session: here the app's connector status for the session does map each UUID to its display name. The name is known; it just isn't the one in the namespace.

The adjacent issues argue for the same fix. On #78044 you closed with this rationale:

What the menu does show next to each entry is where it came from (user, project, or the plugin name), which is the disambiguation that matters for precedence.

I accept that, and it's why I didn't argue that one further. But it is also precisely what this issue reports missing. In the Cowork session I quoted there was no "where it came from": the namespace was a UUID, the server-instructions heading was the same UUID, and the installed-connector listing came back empty. The principle you used to close #78044 — that provenance is already surfaced, so a type distinction isn't needed — is the principle this issue says Cowork breaks. Applied here, it argues for a fix rather than a dismissal.

#78043 is the same defect class, and it is still open with a bug label: a skill I wrote myself appearing under anthropic-skills:, a namespace asserting a provenance that isn't true. This issue is that defect with the sign flipped — the namespace asserts nothing at all, while the identity block asserted something false (in that session, 363d8e44-… introduced itself as "DeepWiki MCP"; its tools were Devin's). If a namespace that overclaims ownership is a bug, a namespace that conceals it is the same bug.

Both halves are one rule about who a name belongs to, and right now that rule has different answers depending on the surface. The ask is still small: name claude.ai connectors mcp__claude_ai_<connector-name>__<tool> in the desktop app as well, the convention you already described in this thread.