Setup
One protocol. Seven places the list of servers actually lives.
MCP standardised how an agent talks to a server. It did not standardise where the server is written down — so the same connector is declared under three different keys, in two file formats, at five different scopes, across the tools one company runs.
how these pages are written
Every file path, JSON key, TOML table and CLI flag on these pages was read from the vendor's own current documentation on 2026-07-26, and each page links the exact page it came from.
Where a vendor's documentation is not publicly reachable, the page says so and publishes nothing rather than guessing. An invented settings path is worse than a missing one — a reader who follows it and fails does not come back.
The divergence, in one table
5 surfaces keep servers in a file and 2 administer them in a console. Among the file-based ones there are 3 different top-level keys — which is why a definition copied between two tools can produce a valid file that declares nothing.
| surface | key | format |
|---|---|---|
| Claude Code | mcpServers | JSON |
| Cursor | mcpServers | JSON |
| Gemini CLI | mcpServers | JSON |
| GitHub Copilot | servers | JSON |
| OpenAI Codex | mcp_servers | TOML |
| Claude.ai | no file — settings | hosted |
| ChatGPT Enterprise | no file — settings | hosted |
What the table is actually evidence of
The immediate consequence is a support burden: a definition copied from one tool's documentation into another produces a file that parses cleanly and declares nothing, which is the single most common MCP failure and costs somebody an afternoon each time it happens.
The structural consequence is bigger. Because there is no shared location, there is no shared list — and because there is no shared list, the same server can be connected to four tools on one laptop, at four different scopes, holding four differently scoped credentials, reviewed by nobody. Every vendor's admin console can honestly report that its own surface is governed while that sentence stays true.
The other half is scope. Most of these surfaces support a personal scope that follows an engineer into every project they open, including repositories whose owners never reviewed it. That scope is where unreviewed servers accumulate, and it is invisible to the project-level review that people assume is catching things.
None of this is a criticism of the protocol. MCP standardised the wire, which was the hard part and the right part. Configuration was always going to be each host's business — which is exactly why the inventory has to be somebody's job at the organisation level rather than each vendor's.
- config file
Claude Code
Claude Code has the most explicit scope model of any surface here — three places a server can live, a documented precedence order, and an approval step for the one that arrives through version control. That structure is a gift to a platform team, and it is worth understanding before you paste anything.
Anthropic · 3 config locations
- config file
Cursor
Cursor uses the same two-file pattern most editors settled on — one in the project, one in your home directory — and layers a genuinely detailed set of team and enterprise controls on top. If you are governing Cursor at scale, the second half of this page matters more than the first.
Anysphere · 2 config locations
- config file
GitHub Copilot
Copilot's MCP setup has one detail that catches almost everyone: the config key is not the one every other surface uses. Get that wrong and the file parses fine and nothing connects. The other thing worth knowing is that in Business and Enterprise, MCP is gated by an organisation policy that is off until someone turns it on.
GitHub · 2 config locations
- config file
Gemini CLI
Gemini CLI's MCP configuration is conventional in shape and unusual in one respect: it exposes per-server tool filtering and a `trust` flag that skips confirmation dialogs entirely. Both are genuinely useful. The second is the field most worth having an organisational opinion about before anyone uses it.
Google · 2 config locations
- config file
OpenAI Codex
Codex is the odd one out in this set: its configuration is TOML rather than JSON, which means a definition copied from any other surface's documentation needs translating rather than pasting. That friction is small, and it has one useful side effect worth naming.
OpenAI · 2 config locations
- hosted console
Claude.ai
Claude.ai is the first surface here with no config file to edit. Custom connectors are remote MCP servers added through settings, and on Team and Enterprise plans only owners can add them — which makes this the one surface in this set where the default is centralised rather than per-machine.
Anthropic · no config locations
- hosted console
ChatGPT Enterprise
ChatGPT is a hosted connector surface — there is no file on a laptop to edit or audit. That shapes the governance story more than any individual setting does, and it is what this page is about. Where we could not verify a current admin click-path from publicly reachable documentation, we say so instead of guessing.
OpenAI · no config locations
Frequently asked
- Is the MCP config format the same across tools?
- The per-server fields are broadly similar — a command and arguments for a local process, a URL and headers for a remote one — but the container is not. Claude Code, Cursor and Gemini CLI use `mcpServers`; VS Code and Copilot use `servers`; Codex uses a `[mcp_servers.<name>]` TOML table. Claude.ai and ChatGPT have no file at all.
- Why does my copied MCP config silently do nothing?
- Almost always the top-level key. A file using `mcpServers` in a place that expects `servers` is valid JSON that declares no servers, so there is no parse error to point at. Check the key before you check anything else, then check whether an organisation policy is gating MCP for that surface.
- Which surface has the strongest native MCP governance?
- It depends on which control you mean, and they genuinely differ. Claude.ai centralises addition to owners on Team and Enterprise plans, which is the strongest default. Cursor documents the most detailed enterprise policy surface, including network access restriction for user-configured servers. Copilot gates MCP through an organisation policy that is off by default. Each page covers its own in detail.
- Do we need a separate approval process per surface?
- No — you need one, applied to the server rather than to the surface. The same MCP server shows up on several tools, and reviewing it once per tool produces several reviews of varying quality and no shared record. Review the server, record the decision somewhere no single vendor console owns, and let each surface's config be the distribution mechanism rather than the review.
Keep reading
One list, distributed to every surface in the table
Vincosha Registry holds the reviewed, pinned set of MCP connectors once and distributes it to every AI surface your company runs, whatever key each one wants it under. Vincosha Assay vets a server before it enters that set, and Vincosha Ledger records which versions were live in the session you are investigating.