Model Context Protocol

What it isCopy Anchor Link

An MCP server exposes tools, resources and prompts over a defined protocol. An MCP client, built into an app such as an IDE or coding agent, connects to servers and makes their tools available to the model. Servers run locally over stdio or remotely over HTTP. Existing servers cover things like GitHub, databases, browsers and file systems.

What to watchCopy Anchor Link

Every connected server adds tool descriptions to context, so a dozen servers can eat the window before work starts. Connect only what the task needs. Servers also run with real permissions, so a server you did not write is code you are trusting. Read what it can do, scope its access, and be careful when it mixes private data with untrusted content. A different approach is to let the agent call tools through code it writes, which keeps unused tool definitions out of context.

A worked example: connecting one serverCopy Anchor Link

You add a "filesystem" server to your coding agent, pointing at one folder. The agent now lists a tool such as read_file and can use it when you ask "summarize the notes in this folder". You added no code. You added a connection. Later you add a calendar server the same way.

Be selectiveCopy Anchor Link

Every server's tool descriptions are loaded into the model's context. Ten servers can use thousands of tokens before you ask a question, and they confuse tool choice. Add the ones you need today.

How a connection worksCopy Anchor Link

1. The host app starts a local server or connects to a remote one.
2. Client and server exchange a handshake saying which features each supports.
3. The client asks for the list of tools, resources and prompts.
4. The tool descriptions are added to the model's context.
5. When the model asks for a tool, the client forwards the call. The server runs it and returns the result.

MCP is plumbing. It makes connecting easy, but it does not make the model better at choosing tools. Results still depend on how clear the descriptions are.

What the context cost looks likeCopy Anchor Link

Invented numbers for illustration: 8 servers with 6 tools each is 48 tool descriptions. At about 150 tokens each, that is 7,200 tokens spent before you type a word. In a 100,000 token window, that is 7.2 percent. It also gives the model 48 choices, and more choices raise the chance of a wrong pick.

A second example: when MCP is not neededCopy Anchor Link

Your own app has two tools and nobody else will use them. Plain functions in the same codebase are simpler. MCP pays off when many apps share an integration, or when you want a third-party server that someone else maintains.

What goes wrongCopy Anchor Link

The tools never appear. The server failed to start because of a wrong path or a missing runtime. Run the server command by hand in a terminal and read its error.

A local server using stdio breaks silently if it prints debugging text to standard output, because that channel carries the protocol. Log to standard error instead.

Two servers expose tools with similar names and the model confuses them. Disable one and test again.

Try it yourselfCopy Anchor Link

Connect one reference filesystem server to a folder holding three small text files. Ask the agent to summarize them, then ask about a file outside that folder. Expect the first to work and the second to fail or be refused. That boundary is the scope you set.

Common mistakeCopy Anchor Link

Installing servers from strangers without reading what they can do. A server can read files or act with your accounts.