three things MCP can do, and an infinite number of things it can’t do (all of which make it great)

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

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

While “run a bash command” covers most things you want it to do, it also covers everything you don’t want an agent to do. The agent 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. For instance, 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.