What Is MCP? Game Changer or Just More Hype?
The hype for Anthropic’s Model Context Protocol (MCP) has reached a boiling point. Everyone is releasing something around MCP to ensure they aren’t seen as falling behind in the ever-changing AI landscape.
However, in this mad dash, confusion remains around MCP and what the standard actually enables. Some see MCP as a total game changer, and some see it as little more than a thin and unnecessary wrapper.
As usual, the truth lies somewhere in between. Let’s dive into the details.
What Is MCP?
MCP was released by Anthropic in November 2024 to minimal fanfare. The protocol was billed as a universal, open standard detailing how AI assistants can gain context — external data, tools and services — to help accomplish tasks. After some bigger players in the AI space adopted the standard, interest in it exploded earlier this year.
So why do models need additional context? Well, for example, say a user prompts a large language model (LLM) with:
“Can you draft a follow-up email to Acme Corp that references our last call and ties in the pricing slide from my proposal deck?”
No LLM in the world can successfully complete this task without additional context: access to the call transcript and proposal slide deck, knowledge of Acme Corp, etc. However, without a standard, the LLM needs a custom integration to access each piece of context, leading to fragmented, inconsistent experiences, thereby slowing down the development of AI applications.
MCP is just a standardized way (i.e., a protocol) for LLMs to access the context they need to accomplish tasks. There are plenty of great resources that get into the weeds of the protocol and the underlying transports, but for now, let’s just define the core entities at play:
- LLM: The large language model that interprets user input and any additional context.
- MCP host: The runtime environment (e.g., a chatbot) that connects an LLM with one or more MCP clients.
- MCP client: A component running inside the MCP host that maintains 1:1 connections with MCP servers and relays context to the LLM.
- MCP server: A service exposing context in a standardized format to MCP clients.
- Context types: Four structured primitives — tools, resources, prompts and sampling — that an MCP server can provide to an LLM.
Host or Client: What’s the Difference?
Initially, many people find the difference between the MCP host and the MCP client confusing, as the distinction is subtle. The MCP client operates within the context of the host (e.g., Claude Desktop), using the host’s capabilities and user interface to initiate requests and consume services offered by MCP servers.
Clients have a 1:1 connection with servers; therefore, a new client process must be spun up on the host for every new MCP server. However, these dedicated “internal clients” aren’t separate user sessions; they’re part of a single orchestrator instance. For simplicity’s sake, we’ll combine the concept of MCP host and MCP client and just refer to a singular MCP client in this article.
These entities work together to create a consistent approach in providing additional context to models. This context can be anything from callable functions (like tools) to text files (such as resources) to parameterized prompts that guide the LLM into a structured workflow.
To illustrate, let’s walk through a simple example of MCP in action. Let’s say a user asks a chatbot something that requires additional context beyond the model’s training data, such as, “What’s the weather in San Francisco today?”
The MCP client first ensures it has up-to-date tool definitions from connected MCP servers. It injects the get_weather tool into the conversation context before sending everything to the LLM. The LLM recognizes the need for additional context to answer the query and invokes get_weather(city="San Francisco") with the appropriate parameters.
The MCP client routes this tool call to the correct server, which executes the logic — calling a weather API — and returns the result. This data is passed back to the LLM, which is leveraged to craft a final response for the user.
Source: Kong
Notably, the actual logic executed here is just a standard API call, which illustrates an important point. MCP does not replace APIs; it’s just an additional interface to make APIs more LLM-friendly.
Tool Calling … Repackaged?
One of the first things people notice about MCP is that it’s not doing anything totally novel. This leads to some common objections:
- It’s just tool calling repackaged.
- It’s a thin wrapper on APIs.
- Why not just use REST or gRPC?
Most importantly, people ask, “So what?” They see hype without substance.
In its simplest form, yes, you could just view MCP as tool calling repackaged. (We’ll get to what makes it more in the next section.) But let’s go back to Anthropic’s mission statement for this protocol: It’s all about defining an open, universal standard. The focus here is on driving innovation through interoperability in this rapidly evolving space.
Still, many ask why we need a layer on top of existing APIs with well-defined standards? Consider a REST API defined by OpenAPI specification that’s both machine and human readable. The spec defines things like what endpoints exist, what parameters are required, what the response might look like, etc. In other words, it tells you how to call an API.
What it doesn’t tell you is why or when to call it, or how to interpret the response — all things an LLM, especially autonomous agents, need to reason effectively. For example, a POST /todos endpoint might let you create a task with a task_description parameter, but it lacks any guidance on how it maps to a goal like “plan my day.”
This combination of reflection and intention-based communication, describing the “what” instead of the “how,” enables more resilient systems.
In contrast, MCP wraps that same function add_task(task_description) with a natural language prompt that describes its intent — e.g., “Given a goal like {user_goal}, break it down into tasks and call add_task to add them to a to-do list.” This additional context helps LLMs to reason about when and why to invoke tools, enabling goal-driven, not hard-coded, logic.
Additionally, REST APIs don’t support a concept called “reflection” — the ability for a client to ask a server, “What functions do you offer, and how do I call them?” That’s essential for dynamic, model-driven interactions. This requirement immediately leads people to look to gRPC, which does support reflection and defines callable functions with structured inputs and outputs (i.e., tools) via protocol buffers.
But gRPC wasn’t built with language models in mind. gRPC prioritizes performance and uses a compact binary format between machines. Its schemas are terse and lack natural language descriptions. While efficient, this makes gRPC interfaces difficult for LLMs to understand without extra tooling or translation. MCP, on the other hand, uses plain JSON with embedded descriptions and usage guidance for each tool, making it far easier for LLMs to interpret and use. MCP effectively serves as a bridge between traditional RPC systems and AI-driven tool use.
This combination of reflection and intention-based communication, describing the “what” instead of the “how,” enables more resilient systems. Dylibso CEO Steve Manuel aptly describes MCP as “the differential for modern APIs and systems.” This resilience is achieved by allowing clients to dynamically discover server capabilities at runtime instead of build time, and semantic parameters, which use human-readable and conceptually focused definitions, make MCP-based integrations capable of seamlessly handling changes to the underlying API.
Coming Up Next
OK, so hopefully now you’re at least starting to see MCP as a necessary and valuable standard, but perhaps you’re still confused why there’s so much buzz around it. In part 2, I’ll take a look at something else MCP offers — enabling agentic workflows — and in part 3, I’ll get into an important shift that is taking place in the MCP ecosystem: remote MCP servers.
Want to learn more? See how Kong is solving real-world MCP server challenges today.
