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 bundles with Yaw Team

The shape of the fix hasn’t changed -- one central definition that every machine reflects -- but the implementation now lives in Yaw Team on top of the local-first Yaw MCP CLI. An admin defines the team’s MCP server bundle once; every team member’s yaw-mcp sync pull mirrors it onto their machine.

Each developer installs the CLI once:

npm install -g @yawlabs/mcp
yaw-mcp install <claude-code|claude-desktop|cursor|vscode>
yaw-mcp sync pull

install wires Yaw MCP into the client of their choice -- one entry, picks the right config file path for the OS, no hand-editing JSON. sync pull mirrors the team-canonical bundle onto their machine. The next yaw-mcp sync pull picks up any changes the admin pushed in the meantime.

One entry. One license key per developer. The key determines which teams they belong to and which bundles they can pull. Add a server to the team bundle and every member picks it up on their next sync. Rotate a credential in the team bundle and nobody’s local config needs to change.

How the merge works

Each developer can belong to multiple teams and also have personal server bundles. When yaw-mcp sync pull runs, it merges:

Personal servers - servers the developer configured for themselves
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:

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

After:

Invite them to the team in the Yaw Team dashboard
They activate their Yaw Team license key
They run npm install -g @yawlabs/mcp && yaw-mcp install <client> && yaw-mcp sync pull
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 bundles handle everything else. Yaw MCP merges them into a single unified view.

Get started

Pick up a Yaw Team license
Define your team’s MCP server bundle and push it with yaw-mcp sync push
Invite your teammates and share their license keys
Each teammate runs npm install -g @yawlabs/mcp && yaw-mcp install <client> && yaw-mcp sync pull

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.