How MCP servers actually behave in a real repo

The Model Context Protocol is a wire format for handing an agent tools, and MCP servers are the processes that expose those tools. A server can run locally over stdio or sit behind an HTTP endpoint. When the agent starts, it asks each server what it can do. Every tool it gets back is described in the model's context window before you type a single word.

That last sentence is the whole story. An MCP server is not free. It is a standing tax on every turn of every session in that project.

The cost nobody measures

We sit with teams who have twelve servers connected and wonder why the agent has gone vague. Open a fresh session, ask what tools are available, and count. A single chatty server can publish forty tools, each with a name, a description, and a full JSON schema. Three of those and you have spent a meaningful slice of the window before the agent has read one line of your code.

Symptoms we see in the room:

• The agent picks a tool that is nearly right instead of the obvious one, because two servers expose similar verbs
• Long sessions degrade faster than they used to
• The agent stops reading files and starts guessing from tool output
• A server that needs auth fails silently on startup and nobody notices for a week

Scope MCP servers per project, not globally

Install globally and you carry your database tooling into a docs repo. Most clients let you register a server at user scope or project scope. Use project scope by default. A repo that never talks to a browser has no reason to load browser tools.

Check what is actually connected before you debug anything else. In Claude Code that is claude mcp list. If a server shows as failed, fix it or remove it, because a half-connected server still burns startup time and still confuses the agent about what is possible.

Write the config into the repo so the whole team gets the same set. A committed .mcp.json beats nine developers with nine different tool surfaces producing nine different agent behaviours on the same task.

Where servers earn their place

The ones that survive our audits share a shape. They reach data the agent cannot get from the filesystem, and they return small answers. A server that queries your issue tracker is worth it, because the alternative is you pasting ticket text. A server that wraps git is usually not, because the agent already has a shell.

Read permissions and write permissions deserve different treatment. Anything that can post, merge, deploy, or delete should require confirmation every time, even when that gets annoying. Especially when it gets annoying.

Do this today

List your connected servers. For each one, name the last task where it changed the outcome. If you cannot name it, disconnect the server and work for a week without it. Almost nobody adds it back. Then commit the surviving list to the repo so new joiners inherit a tool surface someone chose on purpose.

If you want help putting this into practice, talk to us.