One MCP server vs a config file per agent
When a per-client list of local MCP servers is enough, where it stops scaling, and what changes once a team points every client at one remote server.
A config file per agent means each client on each machine lists its own MCP servers and holds its own credentials. One remote MCP server means every client points at one URL, signs in once, and receives the tools, memory and budgets the organization set up. The first fits one person on one machine. The second fits a team.
What does the config-file approach look like?
Most MCP clients read an mcpServers map. Each entry names a server, usually a local process over stdio, and the credentials it needs live in that entry or in the environment it starts with. A Notion server with a Notion token, a GitHub server with a GitHub token, a database server pointed at localhost.
This works well. It needs no third party. The tools run on your machine and talk to the vendor directly. For one person with one client and one or two tools, there is nothing to improve, and the rest of this post does not apply.
Where does it stop scaling?
The cost shows up as a product of two numbers: clients times apps. Each client re-registers each server. Each registration holds a credential. When a token rotates, every file that holds it is edited. When a teammate joins, they repeat the whole setup and connect their own accounts to each app.
Three smaller problems follow. Duplicate registrations collide on tool names, so an old entry and a new one for the same server fight over the same tools until one is removed. Each client prompts for permission in its own way, so the rule "ask before posting to a public channel" is configured once per client, if the client supports it at all. And the spend is spread across vendor invoices with nothing joining them to the agent run that caused them.
The credentials are the hardest part. A token in a config file sits next to the agent's process, in its environment, and often in its transcript. A shared bot account ends up pasted into several people's files, and revoking it means finding every copy.
What changes with one remote server?
Every client gets the same entry, added at user scope so it applies to every project:
claude mcp add corespeed https://api.corespeed.io/mcp --transport http --scope userCodex, Cursor, Copilot and any client with an mcpServers map take the equivalent one-line entry, documented on the MCP server page. The client signs in through the browser, or sends an API key where no browser exists.
From there, tools/list is caller-specific. It returns the tools of the apps this sign-in can reach, the built-in capabilities that are on, and the account tools. A connection made once as shared appears for every member and every client. An org integration such as Slack's workspace bot is connected once by an admin. Credentials stay in the platform's custody, and the agent receives tools, never the token. The connectors page covers the three ways to connect.
| Concern | Config file per agent | One remote server |
|---|---|---|
| Where credentials live | In each config file or environment | Platform custody; the agent gets tools only |
| Adding an app for the team | Each person edits their own config | Connect once, mark it shared |
| Rotating a credential | Edit every file that holds it | Reconnect once |
| Tool list | Whatever the file names | Caller-specific tools/list |
| Approval rules | Per client, where supported | One policy for every client |
| Cost | Separate vendor invoices | One ledger, itemized per call |
| Memory | Per client, if any | Org-owned, shared or private |
Approvals, budget and the trail follow from the same shape. Smart Approval sits between the tool call and execution, so one plain-English policy covers Claude Code, Codex, a bot built with an SDK, and a nightly job alike. Every metered call lands in one ledger, with spend caps on each API key and a threshold on the organization wallet. Every call is attributed to a member or an agent in Dashboard → Activity.
When is a local config still the right choice?
Several cases. A server that must stay on the machine, such as a filesystem server or a database on localhost, has no reason to go through a remote gateway. A single-purpose tool used by one person has no team to share with. A vendor with no connector on the index still needs its own server, until an org admin registers it as a remote connector.
The two approaches also combine. A remote server does not object to local servers alongside it. Keep the filesystem server local and reach Notion, Slack and GitHub through the shared one. One security note applies when you mix: content fetched through any server can carry instructions aimed at the agent, so keep the client's confirmation on for writes when several servers are connected.
The honest limit of the remote approach is scope. A gateway sees only the calls routed through it. A shell command the agent runs locally, or a tool from a different server, never passes the gate, the ledger, or the trail.
FAQ
Do I lose my existing local servers?
No. Add the remote server at user scope and keep the local ones. Remove only an older corespeed entry, since duplicate registrations collide on tool names.
Does every teammate still need to sign in? Yes, once per client. Sign-in is the identity; what each person then sees is their private connections plus the organization's shared ones.
Who can connect a shared account? Any member can connect an account as shared. Organization integrations such as Slack's workspace bot are connected by an org admin only.
What about a job with no browser?
It sends an API key in the header. An unattended job should carry an agent key (sk-csa-), which reaches shared connections only. See the authentication page.
Can I add my own MCP server to the shared surface?
An org admin registers any HTTPS MCP server as a remote connector. Its tools appear as org__slug__tool with the same sign-in, holds and trail.