MCP: Overhyped, Misunderstood, and Actually

Useful
The number of MCP (Model Context Protocol) myths floating around lately is piling up.
Here’s our attempt to give you the nuanced perspective it deserves.
KIRITI BADAM
APR 05, 2025

47 4 Share

This is a guest post by Kiriti Badam

MCP has been becoming more popular in the AI community lately - and it comes with
a LOT of myths and over-selling. It's a perfect example where folks unfamiliar with
software engineering principles start over-hyping what it means for LLM applications.

MCP = Model Context Protocol. Let's breakdown each letter in MCP, explain what
was possible before MCP and what exactly is MCP bringing to the table.

This is a great visualization of MCP, and one of our personal favorites. Created by:
Norah Sakal. Each of these terms will become much clearer as you read through this
article.
What is "Model Context"?
The Nuanced Perspective is a reader-
supported publication. To receive new posts
and support my work, consider becoming a free
or paid subscriber.

"Model Context" refers to the structured information you give an LLM to help it
perform better on your application specific tasks — whether that's accessing tools,
understanding system state, or interacting with external data like user files, databases,
or APIs.

It's a simple idea: LLMs are stateless and context-hungry. You need to give them all
relevant information to reason well. "Model Context" is just the organized way of
doing that.

Before we jump into Protocol (P in MCP), let's understand what was possible before
MCP and why it was a problem.

Myth Buster #1:

"With MCP, I can now connect LLMs to APIs!"

NO. You've been able to connect LLMs (at least OpenAI models) to APIs for over 18
months — since OpenAI launched function calling. Reference:
https://openai.com/index/function-calling-and-other-api-updates/.

So what is function calling?

Function/Tool calling is a pattern where you provide a list of tools and their
descriptions to an LLM along with the user query. LLM can then reason and decide
which function to call. Remember that LLMs cannot execute your code, they can only
return a structured payload (typically JSON) that tells a developer or runtime
environment: "Here's the function you should call, with these arguments."

For example:
# 1. DESCRIBE your function to the LLM - here we're describing a
function to get stock price
tools = [{
"type": "function",
"function": {
"name": "get_stock_price",
"description": "Get current stock price",
"parameters": {
"type": "object",
"properties": {
"symbol": {"type": "string", "description": "Stock
symbol (e.g., AAPL)"}
},
"required": ["symbol"]
}
}
}]

# 2. LLM DECIDES to call the function when appropriate

response = client.chat.completions.create(
model="gpt-4",
messages=[{"role": "user", "content": "Apple stock price?"}],
tools=tools
)

# 3. EXECUTE the function in your code

tool_call = response.choices[0].message.tool_calls[0]
stock_price =
fetch_real_stock_price(json.loads(tool_call.function.arguments)
["symbol"])

# 4. RETURN results to the LLM. The structure of the message is VERY

IMPORTANT.
final_response = client.chat.completions.create(
model="gpt-4",
messages=[
{"role": "user", "content": "Apple stock price?"},
response.choices[0].message,
{
"role": "tool",
"tool_call_id": tool_call.id,
"name": "get_stock_price",
"content": f"${stock_price}" # "The price of AAPL is
$191.52"
}
]
)
 # Result: "Apple's current stock price is $191.52"

This pattern was a game changer. It turned LLMs from passive text generators into
reasoning engines that can orchestrate other tools and get things done.

So what's the problem?

Each provider came up with its own way of describing tools and parsing responses.
OpenAI, Anthropic, Google etc. — all slightly different. And as the ecosystem
matured, this fragmentation became painful. For e.g. OpenAI calls the parameters as
parameters whereas Anthropic calls it input_schema
(https://docs.anthropic.com/en/docs/build-with-claude/tool-use/overview#specifying-
tools).

Enter the "Protocol" in Model Context Protocol

Here's the big idea: MCP is a unified way to describe and handle these function call
patterns, across providers.

If you're familiar with APIs, think of this like REST vs SOAP vs GraphQL. We needed
a shared convention.

With MCP, everyone (clients, servers, models) can agree on:

How tools are described

How requests are issued

How responses are structured

How context (like files or user state) is shared

That's the "protocol" part!!

Myth Buster #2:

"MCP enables tool discovery!"
Nope. Tool discovery isn't new. Even early function-calling models could "discover"
tools. As you saw in the earlier example - if you gave them a list of JSON tool
descriptions, the model could reason: "Oh, get_stock_price looks useful here."

What MCP does is standardize this discovery process.

That means:

Everyone uses the same field names

The structure of the tool descriptions is predictable

You don't need to rework descriptions per model provider

It's not discovery that's new — it's consistency.

Myth Buster #3:

"Without MCP, I had to rewrite code for each application like RAG, Chatbot, Agent
etc.!"

Not true again! You only needed to change your logic when switching LLM providers
— because each had their own quirks.

With MCP, you can now switch providers without touching your tool descriptions.

That means:

Easier provider switching

Easier testing across models

Less glue code and less vendor lock-in

Myth Buster #4:

"MCP allows companies to provide a way to connect LLMs to their tools - which
wasn't possible before!"
Not true! Companies (like booking.com) could provide a Python script containing
functions with @tool decorator and it'll work. The problem would be needing to
create multiple such scripts for different providers.

So... is MCP just JSON schema unification?

Glad you asked. Yes, the immediate benefit of MCP is about agreeing on a JSON
schema — for both requests and responses.

But that unlocks much more.

When everyone speaks the same protocol:

You can handle richer content like audio/video etc.

You can expose files or other resources in a structured way

Think of it like two humans agreeing to speak English. Once the basic vocabulary is
shared, you can discuss anything — from dinner plans to quantum mechanics.

So what's inside MCP?

Here are the key components from the MCP architecture:

🧠 Host
The Host is an LLM application (like Claude Desktop or Cursor) that initiates
connections.

📡 Client
Maintains a 1:1 connection with servers, and lives inside the host application. It sends
messages, receives responses, and handles the communication protocol.

🛠 Server
Provides context, tools, and prompts to clients. It handles the execution of functions,
manages state, and owns the implementation logic.
The magic happens when all these components communicate using the standardized
protocol layers:

Protocol layer - Handles message framing, request/response linking, and

communication patterns

Transport layer - Manages the actual data exchange (via Stdio or HTTP with SSE)

Message types - Standardized formats for requests, results, errors, and

notifications

You can read more details about the MCP architecture here.

Why does MCP matter?

Here are some other reasons developers are excited:

Separation of concerns: Clients don't need to be mixed with tool implementation

details. State management can be off-loaded to servers - which is how it should've
been all along.

Rich data exchange: Audio, video, file metadata, or search index references — all
can be modeled cleanly.

Stateful agents: Servers can retain context across requests. Clients stay simple.

TL;DR
MCP has not invented the way to connect tools to an LLM - it's just a protocol for
doing what we've already been doing — just better, cleaner, and more interoperably.

Much like HTTP for the web or USB for hardware — it's the unsexy infrastructure
layer that will quietly power the next generation of LLM apps.

And that's worth getting excited about!

References & Further Reading:

 Official Docs

MCP GitHub

Collection of MCP Servers

Build an MCP Server From Scratch

The Nuanced Perspective is a reader-

supported publication. To receive new posts
and support my work, consider becoming a free
or paid subscriber.

47 Likes ∙ 4 Restacks

A guest post by
Kiriti Badam Subscribe to Kiriti
Read more about me here - https://www.linkedin.com/in/sai-
kiriti-badam/
Discussion about this post
Comments Restacks

Write a comment...

© 2025 Aishwarya Naresh Reganti ∙ Privacy ∙ Terms ∙ Collection notice

Substack is the home for great culture