How MCP servers actually behave in a real repo

This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.

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. Clients discover the server’s available tools. How much of each schema enters model context depends on the client: tool search can defer loading until a tool is relevant. Measure your client’s actual context and startup behavior rather than assuming every schema is sent on every turn.

The cost nobody measures

A team with many connected servers should inspect which ones a task actually needs. 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 to investigate:

• 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.

Commit reviewed server configuration without credentials so the team shares intended integrations. Effective access still depends on each account’s permissions. 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

A useful selection criterion is simple. 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. Compare task completion and missing capabilities before deciding whether to restore it. 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.