MCP allows LLM clients you don’t control—like Claude, ChatGPT, Cursor, or VSCode—to interact with your API. Without it, you’d need to build your own custom client using the LLM API, which is far more expensive than just using existing clients like ChatGPT or Claude with a $20 subscription and teaching them how to use your tools.
I built an MCP server that connects to my FM hardware synthesizer via USB and handles sound design for me: https://github.com/zerubeus/elektron-mcp.
But couldn't you just tell the LLM client your API key and the url of the API documentation? Then it could interact with the API itself, no?
Not all clients support that—currently limited to ChatGPT custom GPT actions. It’s not a standard. Fortunately, Anthropic, Google, and OpenAI have agreed to adopt MCP as a shared protocol to enable models to use tools. This protocol mainly exists to simplify things for those building LLM-powered clients like Claude, ChatGPT, Cursor, etc. If you want an LLM (through API calls) to interact with an your API, you can’t just hand it an API key and expect it to work—you need to build an Agent for that.
In some sense that is actually what MCP is. A way to document APIs and describe how to call them, along with some standardized tooling to expose that documentation and make the calls. MCP hit a sweet spot of just enough abstraction to wrap APIs without complicating things. Of course, since they didn't add a bunch of extra stuff ... that leads allowing users to footgun themselves per the article.
You could do that. But then you need to explain to the LLM how to do the work every time you want to use that tool.
And you also run into the risk that the LLM will randomly fail to use the tool "correctly" every time you want to invoke it. (Either because you forgot to add some information or because the API is a bit non-standard.)
All of this extra explaining and duplication is also going to waste tokens in the context and cost you extra money and time since you need to start over every time.
MCP just wraps all of this into a bundle to make it more efficient for the LLM to use. (It also makes it easier to share these tools with other people.)
Or if you prefer it. Consider that the first time you use a new API you can give these instructions to the LLM and have it use your API. Then you tell it "make me an MCP implementation of this" and then you can reuse it easily in the future.
> You could do that. But then you need to explain to the LLM how to do the work every time you want to use that tool
This reeks of a fundamental misunderstanding of computers and LLMs. We have a way to get a description of APIs over http, it's called an open API spec. Just like how MCP retrieves it's tool specs over MCP.
Why would an llm not be able to download an openai spec + key and put it into the context like MCP does with its custom schema?
> Why would an llm not be able to download an openai spec + key and put it into the context like MCP does with its custom schema?
NIH syndrome, probably.
Yes, but then you have to add that yourself to every prompt. It would be nice to tell your LLM provider just once "here is a tool you can use" along with a description of the API documentation so that you could use it in a bunch of different chat's without having to remind it every single time. That way, when you want to use the tool you can just ask for the tool without having to provide that detail again and again.
Also, it would be kind of cool if you could tell a desktop LLM client how it could connect to a program running on your machine. It is a similar kind of thing to want to do, but you have to do a different kind of processes exec depending on what OS you are running on. But maybe you just want it to ultimately run a Python script or something like that.
MCP addresses those two problems.
ChatGPT still doesn't support MCP. It really fell behind Google or Anthropic in the last months in most categories. Gemini pro blows o1 pro away.