

What is MCP?
I’ve seen a lot of confusion around MCP. What is MCP? Does MCP replace tool calls? Should I use MCP with my custom agent? Why use MCP over just an API?
I’ve spent the last few months diving into MCP and building MCP Fabric. Here’s what I’ve learned.
Agent Architecture
Let’s first cover at a high level how AI agents currently work.
Agents are made up of the following components:
- Agent Framework: This is the software layer that executes the agent (Cursor, GitHub Copilot or Semantic Kernel, LangChain, etc.).
- LLM: The underlying Large Language Model that powers the agent (ChatGPT, Claude, Gemini, etc.).
- Tools: Functions provided by the agent framework that the LLM can call.
A note about LLM “memory”: Many people think that LLMs themselves remember their conversation history. This is not the case. The LLM itself is stateless. The agent framework (ChatGPT UI, Cursor, GitHub Copilot, etc.) saves the conversation history and feeds it to the LLM with each new request.
Questions
Okay, back to the original questions.
What is MCP?
MCP establishes a standardized way to provide tools to an agent. Before MCP, if you wanted to give an agent access to a tool you had to bake it into the agent software. This severely limited the capabilities of agents as the agent developer would have to implement every tool themselves. Now with MCP, agents can connect to anyone’s MCP server and use the tools it exposes.
Is MCP the only way to make tool calls?
Nope, tool calls have been around since before MCP. MCP just took off because it allows people to bring their own tools to an existing agent.
Does MCP replace tool calls?
Also no - MCP establishes a standardized way for an agent to connect to external tools. The agent can still include normal non-MCP tools in addition to the MCP tools.
Should I use MCP with my custom agent?
This depends.
If you’re already building all the tools yourself: just bake them directly into your agent - this avoids the additional complexity of MCP. If you’re unsure how to do this, checkout Microsoft Semantic Kernel.
If you want to use an existing MCP server like GitHub or an API -> MCP platform like MCP Fabric, then yes - this is exactly what MCP is for.
Why use MCP rather than just giving an LLM an OpenAPI spec and a single tool to make API requests?
This one is more nuanced and subjective. Here are some of the reasons I believe MCP is more than just an API.
-
Context: The
C
in MCP stands for Context. MCP servers provide context on each tool / resource they expose for the LLM to understand how to use them. Yes, some OpenAPI specs include good documentation, but many don’t. -
Cost: Have you seen an OpenAPI spec? They tend to be massive. Passing the entire spec to an LLM would be rather expensive. Some back-of-the-envelope math: MCP Fabric’s rather small OpenAPI spec is 20,000 tokens. At $3/million tokens for Claude 4, that’s $0.06 just to include the spec in the context window.
-
Complexity: Sure AI is supposed to be intelligent, but most APIs are quite complex and LLMs may struggle to properly format a request. Furthermore, users don’t want to watch an agent try and fail multiple times to get the right format.
-
No Spec: A surprising number of APIs don’t actually have an OpenAPI spec. Why this is when they can be auto-generated is beyond me.
-
Additional Capabilities: Remote MCP servers are currently mostly just wrappers around existing APIs. However, the official MCP spec allows for more advanced capabilities that wouldn’t be possible with a simple rest API. For example, MCP resources allow for streaming real-time resource updates to the agent.
-
Small Language Models: Many people see a future where every smart device has an NPU (Neural Processing Unit) running a SLM (Small Language Model). The small language model could then use MCP to interface with hardware on the device. For example, a car could use MCP to interface with the car’s sensors and controls.
-
Auth: Auth to APIs is complicated. Sure, an LLM could figure it out, but MCP provides a standardized way to handle this.
MCP Fabric
Okay, so we need MCP but the internet is already full of APIs. Now everyone is is just building MCP servers that wrap APIs. Why reinvent the wheel every time and have to deal with all the complexity of building and hosting your own MCP server? Writing code for every tool, dealing with resiliency, scaling, auth, telemetry, hosting, the list goes on. I built MCP Fabric to solve this problem.
MCP Fabric lets you spin up fully hosted MCP servers instantly - just point it at an OpenAPI spec or define routes yourself. It handles the server creation, deployment, hosting, and telemetry (with logs + insights for every tool call -> API request). No code. No setup hell. Just a live, ready-to-use MCP server with tools and resources exposed.
Check it out at mcpfabric.com.
Conclusion
MCP is often fundamentally misunderstood. Hopefully this helps bring some clarity to both MCP and the entire agent ecosystem.
← Back to blog