 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
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.
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:
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.
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.
One of the first things people notice about MCP is that it’s not doing anything totally novel. This leads to some common objections:
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.
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.
