Managing MCP Servers Across a Team

A solo developer with three MCP servers has a config file. A team of ten developers with fifteen MCP servers has a problem.

The problem is not the protocol. MCP works fine. The problem is that every developer on the team maintains their own config, their own API keys, their own server versions, and their own understanding of which servers are current. Multiply developers by servers by machines and you get config drift, secret sprawl, and onboarding friction that scales linearly with headcount.

The config drift problem

MCP clients store server configuration in JSON files. Claude Code uses .mcp.json at the project root and ~/.claude.json globally. Cursor has its own config. Every client, every machine, every developer - a separate copy.

What happens in practice:

• Developer A updates the Postgres server to point at the new staging database. Developer B is still hitting the old one.
• Someone adds a new internal MCP server for the deployment pipeline. Half the team does not know it exists.
• An API key gets rotated. Three developers update their config. Two do not. Their sessions break silently.
• A new hire joins. Someone Slacks them a JSON blob that is already two weeks out of date.

This is the same problem that configuration management solved for servers twenty years ago. But for MCP, everyone is still manually editing files.

The secret sprawl problem

MCP server configs contain credentials. GitHub tokens, Slack tokens, database URLs, API keys - all sitting in JSON files on developer laptops. These files are not encrypted. They are frequently committed to dotfiles repos. They are copied between machines via Slack DMs.

A single developer’s leaked laptop means every MCP credential they had configured is compromised. With a team, the blast radius multiplies: each developer has their own copy of every shared credential.

The right answer is not “be more careful.” The right answer is to not distribute credentials to developer machines at all.

Centralized config with mcp.hosting Teams

mcp.hosting Teams solves this. An admin defines the team’s MCP server configuration once, in the mcp.hosting dashboard. Every team member gets those servers automatically.

The developer’s config stays simple:

{
  "mcpServers": {
    "mcp.hosting": {
      "command": "npx",
      "args": ["-y", "@yawlabs/mcph"],
      "env": {
        "MCPH_TOKEN": "mcp_pat_..."
      }
    }
  }
}

For onboarding a new teammate, that’s now a single command: npx -y @yawlabs/mcph install <client> --token mcp_pat_<their-token>. mcph edits the right config file and saves the token to ~/.mcph.json so every MCP client on their machine inherits it. No copy-pasting JSON, no per-OS file path lookups, no “wait, where does Cursor read its config from?”

One entry. One token per developer. The token determines which teams they belong to and which servers they can access. Add a server to the team config and every member picks it up within 60 seconds. Rotate a credential in the dashboard and nobody’s local config needs to change.

How the merge works

Each developer can belong to multiple teams and also have personal server configs. When mcph starts, it pulls and merges:

1. Personal servers - servers the developer configured for themselves
2. Team servers - servers from every team they belong to

All servers appear in the unified discover list. The developer activates what they need. If a team server and a personal server have the same name, the personal config takes precedence so developers can override team defaults when needed.

Role-based access

Teams have three roles:

• Owner - full control over the team, its servers, and its members
• Admin - can add and remove servers, invite members, and manage configuration
• Member - can discover and activate team servers, but cannot modify the team config

This maps to how most engineering teams already work. The platform team or DevEx team manages the server config. Individual developers consume it.

Onboarding in two minutes

Compare the before and after for onboarding a new developer:

Before:

1. Slack them a JSON config blob
2. They paste it into the right file on their machine
3. Someone sends them each API key separately
4. They edit the config to insert each key
5. They restart their MCP client
6. Something does not work. Debug for 20 minutes.
7. Repeat when they get a second machine

After:

1. Invite them to the team in the dashboard
2. They create a personal token
3. They add the one-line config
4. Done. Every team server is available.

No credentials on their machine. No config to maintain. No drift.

Visibility and control

When servers are centrally managed, you get things that are impossible with distributed configs:

• Who is using what - see which team members are activating which servers
• Instant disable - toggle a server off and it disappears for every team member. Useful when an upstream service is having issues.
• Credential rotation - update a key once, in one place. No Slack messages, no calendar reminders.
• Offboarding - remove a developer from the team and their access to team servers revokes immediately. No need to rotate every credential they had access to.

When to use teams vs. project config

Teams is for servers that the team shares: internal APIs, shared databases, deployment tools, company-wide services. If the server is project-specific and only relevant in one repo, a .mcp.json in the project root is still the right answer.

The two approaches compose. Project-level configs handle repo-specific servers. Team-level configs handle everything else. mcph merges them into a single unified view.

Get started

1. Create a team in the dashboard
2. Add your shared MCP servers with their credentials
3. Invite your team members
4. Each member adds the one-line config to their client

Your MCP configs are now managed infrastructure, not scattered text files.

Jeff Yaw, Yaw Labs. Follow along at tokenlimit.news for weekly notes on AI infrastructure.