The Docker MCP Toolkit naming-ontology pattern
This repo names its own MCP-connected surfaces with a fixed convention: {device_surface}__{client_surface}__{coworker_enum} -- so that code written for one surface can't silently assume tools that are only available on another. This is documented directly in this repo's own CLAUDE.md, under the "Naming ontology" and "macOS Claude Desktop profiles" sections.
Two real instances
| Name | Meaning |
|---|---|
macos__desktop_cowork__engineering_coworker | Claude Desktop Cowork running on macOS, acting as the engineering-coworker persona -- corresponds to profiles/claude_desktop_cowork.json and the Docker MCP profile of the same name, which wires in Cloudflare + GitHub + filesystem + chrome-devtools (npx) + the engineering-coworker Rust binary as MCP servers. |
cloud__docker_mcp__engineering_coworker | Claude inference running in Anthropic's cloud, using the Docker Desktop MCP Toolkit catalog (17 servers snapshotted in Docker Desktop at time of writing) as its MCP source -- still acting as the engineering-coworker persona. |
The rationale, verbatim from this repo's own CLAUDE.md: code written for the cloud__* surface must use mcp__MCP_DOCKER__* tools only, while code for the macos__* surface can use npx/binary MCPs directly on the Mac. This keeps the two execution environments from silently assuming tool availability that doesn't hold on the other side.
Why this matters for connectors generally
Docker Desktop's MCP Toolkit is itself a kind of connector catalog -- a management surface for discovering and connecting MCP servers as containerized services. This repo's naming ontology is a concrete, working example of how to keep track of which MCP servers are reachable from which real execution surface, which is exactly the kind of bookkeeping problem that grows unmanageable once more than a couple of connectors/servers are in play.
Source: CLAUDE.md, "Naming ontology" and "macOS Claude Desktop profiles" sections, this repo.