I have read 30 MCP articles now and I still don’t understand why we not just use API?
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.
> why we not just use API
Did you meant to write "a HTTP API"?
I asked myself this question before playing with it a bit. And now I have a slightly better understanding, I think the main reason was created as a way to give access of your local resources (files, envvars, network access...) to your LLM. So it was designed to be something you run locally and the LLM has access.
But there is nothing preventing you making an HTTP call from a MCP server. In fact, we already have some proxy servers for this exact use-case[0][1].
I'm not sure I get it too. I get the idea of a standard api to connect one or more external resources providers to an llm (each exposing tools + state). Then I need one single standard client-side connector to allow the llm to talk to those external resources- basically something to take care of the network calls or other forms of i/o in my local (llm-side) environment. Is that it?
Sounds mostly correct. The standard LLM tool call 'shape' matches the MCP tool call 'shape' very closely. It's really just a simple standard to support connecting a tool to an agent (and by extension an LLM).
There are other aspects, like Resources, Prompts, Roots, and Sampling. These are all relevant to that LLM<->Agent<->Tools/Data integration.
As with all things AI right now, this is a solution to a current problem in a fast moving problem space.
I have an API, but I built an MCP around my API that makes it easier for something like Claude to use — normally something that's quite tough to do (giving special tools to Claude).
Because you need mainly a bridge between the Function calling schema defined that you expose to the AI model so you can leverage them. The model need a gateway as API can't be used directly.
MCP core power is the TOOLS and tools need to translate to function calls and that's mainly what MCP do under the hood. Your tool can be an API, but you need this translation layer function call ==> Tool and MCP sits in the middle
I played around with MCP this weekend and I agree. I just want to get a users X and then send X to my endpoint so I can do something with it. I don't need any higher level abstraction than that.
If you are a tool provider, you need a standard protocol for the AI agent frontends to be able to connect to your tool.
I think the commenter is asking "why can't that standard protocol be http and open api?"
MCP is a meta-api and it basically is that, but with further qualifications that the endpoints and how they work themselves are part of the spec so LLMs can work with them better.
I think it's fine if you only need a standalone API or know exactly which APIs to call. But when users ask questions or you're unsure which APIs to use, MCP can solve this issue—and it can process requests based on your previous messages.
It is an API. You can implement all this stuff from scratch with raw requests library in python if you want. Its the idea of a standard around information interchange, specifically geared around agentic experiences like claude code, (tools like aider, previously, that are much worse) - its like a FastAPI web app framework around building stuff that can helps LLMs and VLMs and model wrapped software in ways that can speak over the network.
Basically like Rails-for-Skynet
I'm building this: https://github.com/arthurcolle/fortitude
I feel like this is being pushed to get more of the system controlled by the provider's side. After a few years, Anthropic, google, etc might start turning off the api. Similar to how Google made it very difficult to use IMAP / SMTP with Gmail
Right. And if you use OpenAPI the agent can get the api spec context it needs from /openapi.json.
It is an API. It's an API standardization for LLMs to interact with outside tools.
I just want to mention something in a chat in 5 seconds instead of preparing the input data, sending it to the API, parsing the output for the answer, and then doing it all again for every subsequent message.