A coding agent that can only see your repo is working with one eye closed. The ticket it is fixing lives in your issue tracker, the error it is chasing lives in your logs, and the decision it needs lives in a doc somewhere. The Model Context Protocol, or MCP, is the standard way to give an agent access to those things.
This is a practical introduction for engineering teams: what MCP is, how it works, what teams connect, and how to choose servers without opening a hole in your security.
What MCP is
MCP is an open protocol, introduced by Anthropic in late 2024, that defines how an AI application talks to external tools and data. Before it, every agent needed its own integration with every tool. With it, a tool is wrapped once as an MCP server, and any agent that speaks MCP can use it. Claude Code, Claude Desktop, Cursor, Codex, VS Code and many others are MCP clients today.
There are three roles:
- The host is the application you use, such as Claude Code or Cursor.
- The client lives inside the host and keeps one connection to each server.
- The server wraps a tool or data source and describes what it offers.
A server can offer three kinds of things:
- Tools: actions the model can call, like “search issues” or “run this query”. This is what most servers are about.
- Resources: data the application can read, like a file, a document or a schema.
- Prompts: reusable prompt templates the user can pick, often shown as slash commands.
Local and remote servers
MCP servers run in one of two ways, and the difference matters for security and for setup.
Local servers run on your machine as a subprocess of the agent and talk over standard input and output. They can reach anything you can reach: your files, your network, your credentials. They are easy to write, and they are code you are running on your laptop, so treat installing one like installing any other package.
Remote servers run as a web service and talk over HTTP. Authorization is built on OAuth, so you sign in through the provider and grant access, rather than pasting long-lived tokens into config files. For a team, remote servers are usually easier: nothing to install, one place to revoke access.
Adding a remote server to Claude Code is one command:
claude mcp add --transport http docs https://mcp.example.com/mcpTo share servers with the team, check a .mcp.json into the repo. Everyone who opens the project gets the same set, and Claude Code asks each person to approve project servers before using them:
{
"mcpServers": {
"docs": { "type": "http", "url": "https://mcp.example.com/mcp" }
}
}What teams connect
- Issue trackers, so the agent reads the real ticket, comments included, instead of your summary.
- Docs and wikis, for the specs and decisions that never made it into the repo.
- Observability, so an agent fixing a bug can read the actual error and stack trace.
- Databases, read-only and on a replica or a dev copy, for questions about schema and data.
- Design files, to build UI from the real design instead of a screenshot.
- Team memory, so the agent gets the rules and past lessons relevant to the task. That is what Memmo's server does.
What can go wrong
MCP makes agents more capable, and every capability is also a risk. Four to keep in mind:
- Everything a server returns is text in the model's context. A ticket written by a customer, a web page, a log line: any of them can contain instructions aimed at the agent. This is prompt injection, and we wrote a separate guide on it.
- Over-broad access. A server connected with an admin token gives the agent admin powers. Use the narrowest scope that does the job, and read-only wherever possible.
- Supply chain. A local server is a program with your permissions. A server from an unknown publisher deserves the same suspicion as an unknown npm package.
- Too many tools. Each server adds tool descriptions to the context. Connect twenty servers and the agent has less room for your code, and a harder time picking the right tool.
How to choose a server
- Prefer servers published by the vendor of the tool, or ones you can read the code of.
- Prefer remote servers with OAuth over local servers holding long-lived tokens.
- Check what the tools actually do. A server with a “delete project” tool can delete projects.
- Start with two or three servers that remove real friction, and add more only when you miss them.
- Keep the team's set in a checked-in
.mcp.json, and review changes to it like code.
The official MCP Registry is a good starting point for finding servers, with entries tied to the publisher's domain or account.
When to build your own
If your team keeps pasting the same internal information into agent sessions, such as runbooks, the output of an internal API, or deploy status, that is a good candidate for a small internal server. Keep it focused: a handful of tools with clear names and descriptions beats one tool that does everything. The description is what the model reads to decide when to call it, so write it for the model, with an example of when to use it.
MCP is not magic. It is plumbing. But it is the plumbing that decides whether your agent works from what you typed, or from what your team actually knows.