What’s Special About MCP?

AI agents can interact with the world using tools. Those tools can be generic or specific. For example:

Generic:

• Run a bash command
• Operate a web browser
• Execute a SQL query

Specific:

• See my Google Calendar events
• List my tasks in Asana
• Send an email

The most general ones, like “run a bash command” and “read and write files” are built into the agent. More specific ones are provided through Model Control Protocol (MCP) servers.

Every tool provided to the agent comes with instructions sent as part of the context. Each MCP server the user configures clogs up the context with instructions and tool definitions, whether the agent needs them for this conversation or not.

If the agent can run a bash command, it can write a curl command or a script to call an API. Why use an MCP server instead?

MCPs provide three unique abilities

1. Authentication: Authorize an MCP server once* to act as you, and then take many actions, each properly attributed. OAuth is hard and you can’t do it with curl. *OK, it’s more than once, it’s ‘every time it loses the connection.’ This feels like every day, but maybe the agents will get better at renewing auth.
2. Specialized interface: A software API is optimized to talk to code. If it responds with JSON, that is verbose and uses a ton of tokens. An MCP response can summarize the results in text. It can intersperse that with CSV and even ASCII art! It’s more efficient and effective in communicating with an LLM.
3. Change: MCPs don’t have to be consistent from day to day, since every conversation is new. The creators of an MCP server can work on that response and make it more effective, changing its format at need. They can add tools, change tools, and even remove tools that aren’t used enough. Try doing that in a software API! It’d break every program that uses it. MCPs can iterate, and rapid iteration is a superpower that AI gives us.

If you want to teach your agent to do something that doesn’t require authentication—like read a web site—then by all means, let it use the tools it already knows. It can get a long way with curl and jq. Why dilute its world with more instructions when it already knows so much?

It can already:

• Call known APIs with simple auth
• Dig around in a SQL database
• Operate a web page with a playwright script

Specialized MCPs let it:

• Read Figma designs and get just what it needs
• Read and update your Google Calendar
• Look at graphs and traces in ASCII

MCPs don’t let the agent do anything it wants

While “run a bash command” covers most things, it also covers everything you don’t want an agent to do. It can screw with your configuration, write private data out to a public repository, and use your credentials to publish infected versions of your libraries. There is (relative) safety in specific tools. The agent’s filesystem tools reject writes to files outside of the current project. (The agent then asks my permission to do that update in bash. I say no.)

Well-designed MCPs offer the operations that make sense. They’re limited by your authorization as a user, and you can further limit their authorization when you connect or in your agent’s configuration. We can be smarter about it.

Someday, we will have nice things

Currently, if I configure an MCP, it’s available all the time to all agent threads. Most of the time, that’s a waste of my context. I want to configure which subagents know about which MCP, so my “look at production” agent can see my observability platform, my UI-updating agent can see Figma, and my status update agent can see Asana. I also want agents to load MCP context incrementally so that it doesn’t get every tool definition until it asks to see them.

When MCPs don’t hog context, they still won’t often beat using the innate knowledge of the model. But when you are ready to curate the access that agents have to your SaaS or data, MCPs are fantastic.