What do the three admin consoles control?
Each vendor console governs connectors on its own client and nothing else. The switches differ, the plan requirements differ, and so does the vocabulary.
You approved Claude for support, ChatGPT for marketing and Cursor for engineering. Each one now has an admin page for connectors, and none of those pages knows the other two exist. So IT admin controls for MCP connectors is really three questions, answered in three places. MCP (Model Context Protocol) is the protocol an AI client speaks to reach tools outside itself, and a connector is a server it talks to.
This comparison covers Claude, ChatGPT and Cursor. Microsoft Copilot's MCP governance runs through Power Platform data policies, advanced connector policies and the Microsoft 365 admin center. That stack is compared in Copilot Studio vs an MCP gateway. If you run a mixed fleet that includes Copilot, treat the table below as partial.
Everything below is read from each vendor's own documentation, checked October 2026. Date anything you copy out of it, because these consoles move.
| Control | Claude (Team, Enterprise) | ChatGPT (Business, Enterprise, Edu) | Cursor |
|---|---|---|---|
| Who adds a custom MCP server | Owner or Primary Owner; on Enterprise also a custom role with Libraries (Manage) | Admins and Owners publish; on Enterprise and Edu, RBAC can let members build drafts | Team admins distribute shared servers; individuals add their own by URL |
| Allowlist of approved servers | Directory connectors stay off until an Owner adds them | Per-app on or off for the workspace | Policy allowlist, Enterprise only |
| Different apps for different teams | Enterprise custom roles narrow further | Enterprise and Edu only, through custom roles | Team Marketplace distributes; policy is Enterprise |
| Per-tool approval | Always allow, Needs approval or Blocked, per tool or group | Per-app Actions switch read and write actions separately | Approval prompt before tool use, on by default |
| Members can request one | Team members see Request on directory connectors | No request flow documented for custom apps | Not documented |
| Reaches servers on laptops | Anthropic says connector permissions do not govern locally run servers | Not documented | MDM-deployed hooks see each call |
Sources, all checked October 2026: Anthropic's custom connector and directory pages, OpenAI's admin controls for plugins and apps, and cursor.com/docs/mcp.
What can an Owner enforce in Claude's console?
Claude's console governs what an Owner added, on Anthropic's surface only. Directory connectors stay off until an Owner or Primary Owner adds them under Organization settings, then Browse connectors, then Add to your team. Adding connects nobody. Each member still signs in with their own account.
Custom connectors, which is what a remote MCP server is, are added by Owners and Primary Owners. On Enterprise a custom role holding Libraries (Manage) can add one as well. Ordinary members cannot add one; they enable what was added. The order these steps belong in across a whole company is set out in the Claude and ChatGPT rollout sequence.
On Team, members see a Request button on a directory connector. Owners find those requests under Requested by your team in Organization settings, and on the Requests tab in Notifications (claude.com/docs/connectors/directory, checked October 2026). Anthropic's page does not say Enterprise members get the same button, so do not plan around it.
Tool permissions are the sharp control. Per connector, per group or per tool, an Owner sets Always allow, Needs approval or Blocked. Anthropic states the limit in its own words on the custom roles page (checked October 2026). These permissions do not govern connectors a member runs locally on their own machine. That gap is worth treating as critical rather than cosmetic. A Blocked connector in the console does nothing to a copy of the same server a developer points Claude Desktop at locally. Device policy, covered below, is the only lever that reaches it.
What does ChatGPT's console control for MCP apps?
ChatGPT's controls are per app, and on the right plans per role. Apps, formerly called connectors, are managed at Admin Console, then the workspace, then Plugins (help.openai.com, checked October 2026). The older Workspace settings route is still reachable through Manage Legacy Apps. Labels moved during 2026, so date any menu path you write down.
Each app is on or off for the whole workspace. Business apps start on, and new Enterprise and Edu workspaces start with a selected set on. Giving different teams different apps is Enterprise and Edu only, through custom roles under Permissions and roles, then Custom roles, then Plugins and connected data. Roles add up, so any role granting a permission grants it, and changes take up to five minutes (help.openai.com, checked October 2026).
Within an app, Actions turn read and write actions on separately. New actions decides what happens when the app gains more. Plugin permissions decide when ChatGPT asks first: Always ask, Allow read actions, Allow low-risk actions, and per app, Allow all actions. Members of a managed workspace never get a lasting Always allow (help.openai.com, checked October 2026).
Custom MCP apps are published by Admins and Owners only, and on Business only admins use developer mode. A published app runs on a frozen snapshot of its tools, so new actions arrive disabled until an admin refreshes them. OpenAI does not verify custom apps (help.openai.com, checked October 2026). The frozen snapshot is a real failure mode. If a connector publisher adds a destructive new tool after the app was published, ChatGPT members cannot reach it until an admin refreshes the app. That is a safety net, and it also keeps a legitimately useful new read-only tool invisible for the same reason.
One consequence matters for any single-endpoint setup. Elaichi's connected tools are never listed individually; the model finds one with search_tools and runs it with execute_tool. ChatGPT therefore sees one app with a handful of tools, and its per-action switches cannot tell a Salesforce read from a Zendesk delete. Setting the Elaichi app to read actions only does not make the apps behind it read-only. Narrowing ChatGPT's own app list is covered in restricting ChatGPT Enterprise connectors.
What can a Cursor team admin enforce?
Cursor separates distribution from policy and says so plainly. "MCP distribution and MCP policy are configured separately. Team admins can distribute shared MCP servers. Enterprise admins can configure MCP policy" (cursor.com/docs/mcp, checked October 2026). That distinction generalizes beyond Cursor. In every console here, "who can make a server available" and "what that server is allowed to do once available" are separate permission axes. They are often on different plan tiers.
Shared Team MCP servers live under Dashboard, then Plugins and MCPs, and are available to Cloud Agents. Add to Team Marketplace makes one available in the Agent Window, the IDE and the CLI.
The policy allowlist is Enterprise only, and Cursor is explicit about what it does not do. Adding a server to the allowlist does not push it to users' machines. Team members still need to configure the server in their own Cursor settings. Individuals add a remote server by url in .cursor/mcp.json for a project or ~/.cursor/mcp.json globally. Cursor supports OAuth for servers that require it, and asks for approval before using MCP tools by default.
For what the console cannot reach, Cursor documents hooks. An MDM-deployed beforeMCPExecution hook sees the server name and the URL or command on every call. It can allow, deny or ask (cursor.com/docs/hooks, checked October 2026). A device the hooks file never reached runs without the hook, so monitor MDM delivery.
Which servers sit on laptops, and who can see them?
Nobody's console lists them. No client vendor documents an admin inventory of the servers sitting in members' local config files. Admin consoles report only what connects through the vendor's own surface. Finding local servers means reading the files on each device with an MDM or EDR script.
The paths, all checked October 2026. Claude Desktop keeps servers in claude_desktop_config.json under ~/Library/Application Support/Claude/ or %APPDATA%\Claude\ (modelcontextprotocol.io). Claude Code uses ~/.claude.json and a project .mcp.json; ~/.claude.json also holds the sign-in session, so read only its mcpServers objects (code.claude.com). Cursor uses ~/.cursor/mcp.json and .cursor/mcp.json (cursor.com/docs/mcp). Codex uses ~/.codex/config.toml (learn.chatgpt.com). VS Code with GitHub Copilot now steers new servers to .mcp.json at the project root and ~/.copilot/mcp-config.json (code.visualstudio.com). The longer version of this hunt is in find the MCP servers employees have installed.
Device policy is where you close the gap. Claude Desktop reads com.anthropic.claudefordesktop on macOS and HKLM:\SOFTWARE\Policies\Claude on Windows, where isLocalDevMcpEnabled and the two desktop extension keys default to true (support.claude.com, checked October 2026). Claude Code managed settings filter with allowedMcpServers and deniedMcpServers. The denylist always wins, and managed-mcp.json takes exclusive control. Anthropic warns that matching by serverName is not a security control, because users choose the names (code.claude.com, checked October 2026). VS Code ships chat.mcp.access, delivered as the ChatMCP policy, taking all, registry or none. Per-server allow and deny lists sit alongside it, where deny beats allow (code.visualstudio.com, checked October 2026). Devin Desktop, formerly Windsurf, blocks every other server for the team once any server is allowlisted (docs.devin.ai, checked October 2026).
Where IT admin controls for MCP connectors stop short
Every console above governs its own client competently. Three jobs sit outside all of them.
One rule that holds in all three clients. A tool blocked in Claude is not blocked in ChatGPT. An Enterprise allowlist in Cursor says nothing about what a member reaches in the ChatGPT web app. Each decision is written three times, by three admins, in three vocabularies, and starts drifting the day it is written. It fails silently: nothing errors, nothing logs a conflict, the same person simply has different access depending on which app they open.
Per-tool rules for the apps behind one endpoint. Route your clients through a single MCP endpoint and each client sees that endpoint's tools, not the connected tools underneath. For an aggregator like Elaichi that is search_tools and execute_tool. A Claude tool permission set on execute_tool covers every connected tool at once. That is the right granularity for the endpoint and the wrong granularity for Jira versus Salesforce. This only matters if you've put an aggregating endpoint in front of your clients. If every connector is added directly in each console, this gap doesn't apply to you. The choice between those two levels is unpacked in restricting one tool or the whole app.
One audit trail across clients. Anthropic's Compliance API records connector connects and disconnects for Enterprise, with no backfill (platform.claude.com, checked October 2026). OpenAI's Compliance Logs Platform is Enterprise and Edu only, keeps files 30 days, and documents no tool-name field (chatgpt.com admin API reference, checked October 2026). Cursor's Enterprise audit log carries mcp_server_config and mcp_authentication events (cursor.com, checked October 2026). Three formats, three retention windows, three sets of ids, and nothing joins them into an answer about last week's Salesforce changes. This doesn't block anything in real time. It does mean a post-incident investigation across clients requires manually correlating three exports by timestamp and user email, not by a shared id. The shape of the record you actually need is in what an AI agent audit log must capture.
Disclosure, and where the vendor-neutral part of this post ends
Everything above is sourced to vendor documentation, dated, and checked against each vendor's documentation in October 2026. Everything below describes how Elaichi, the product this blog is published by, addresses the three gaps above. It is not vendor-neutral, and it is not independently audited. Read it as one vendor's design decision, not as documentation with the same evidentiary status as the Anthropic, OpenAI and Cursor links above.
Splitting the work: consoles for devices, endpoint for rules
The client console decides which connectors exist on that client and what runs on employee laptops. A separate control plane like Elaichi decides what the approved connector may reach, once, for every client. That is the general shape of the fix for the three gaps above, independent of which vendor implements it.
In the client console, allow only the connectors you approved and govern local servers. That means Claude's device policy keys and Claude Code managed settings, Cursor's Enterprise allowlist plus an MDM hook, VS Code's chat.mcp.access, and ChatGPT's per-app switches. Nobody can do that part for you, because the files sit on the devices.
In Elaichi specifically, a restriction names whole connectors, single tools, or both. It targets a role or a user, which is why each role is written as one complete job. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A user-targeted rule replaces the role's rules rather than layering on them, and blocks always beat allows. An allow rule is the target's whole allowlist across every connector, so every app the rule does not name is denied for that role. Holding one app to reads without touching the rest is done with blocks on that app's write tools.
A withheld tool is invisible. It reaches neither tools/list nor search_tools, and its name never goes on the wire, so the model cannot ask for something it has never seen. Role and restriction changes take effect about two minutes, on the MCP endpoint, the console and the REST API alike. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.
One organization-wide endpoint serves Claude, ChatGPT, Cursor, any MCP client and the Elaichi Agent, so the rule is written once. Each member still connects and signs in with their own OAuth grant. That grant is the browser consent that hands their client a scoped permission to act as them. The audit trail records the surface and the OAuth client each call came through. The client's name is marked verified when its redirect URIs prove it, which covers Claude, ChatGPT and Cursor. A client signing in through a loopback address, such as Claude Code or Codex CLI, shows the name it registered with, marked unverified.
When the client consoles are enough
Skip the second layer when there is nothing underneath it to govern. If your agents only reach servers your own engineers wrote, the client consoles plus device policy are the whole control set. A second vendor buys you nothing.
If you have standardized on Cloudflare Access, Cloudflare's MCP server portals put remote HTTP MCP servers behind one endpoint. That endpoint sits inside the access layer you already run, with per-server sign-in for users (developers.cloudflare.com, checked October 2026). This is a genuinely different shape from Elaichi. Cloudflare fronts servers you or your vendors already run. Elaichi authors and serves 600+ connectors from its own infrastructure, so there are no servers for you to run or list.
Pick based on what your agents reach, not on vendor preference. Servers you wrote point toward a fronting layer like Cloudflare Access; SaaS accounts your staff already hold point toward a managed-connector layer like Elaichi. The architecture behind that split is in what an MCP control plane is. The per-client version of the same argument is in Claude and ChatGPT connectors against one endpoint. The apps the rules apply to are listed at /connectors/.
