I recently attended a meetup where Kaden Wilkinson broke down the evolution of Model Context Protocol (MCP) and its impact on LLM efficiency. The room was packed. The topic was fascinating. And the stat that stuck with me: up to 98% more efficient.
That’s not incremental improvement. That’s a paradigm shift.
Traditional LLM interactions are wasteful. Every time you ask a model to do something, you’re essentially:
It’s like hiring a PhD to do data entry. Yes, the model can do it, but there’s a lot of overhead.
Model Context Protocol standardizes how LLMs interact with external tools and data sources. Instead of:
“Please write Python code to read this file and extract the email addresses”
You get:
[MCP call: file_read(“data.csv”) -> extract_emails()]
The model doesn’t generate code. It calls a function. The execution happens outside the model. The result comes back structured.
The efficiency gains come from multiple sources:
When models generate code, they’re using tokens for:
MCP calls are compact. `file_read(“data.csv”)` is a few tokens. The equivalent Python code might be 50-100 tokens.
Generated code needs to be:
MCP calls are direct function invocations. The interpretation layer disappears.
LLM-generated code is stochastic. You might get slightly different implementations each time. MCP tools are deterministic — the same call produces the same result.
MCP allows for caching at the protocol level. If the model asks for the same data twice, the second call can be cached without the model even knowing.
This is the shift Kaden emphasized: we’re moving from models that “know” things to agents that “do” things.
Knowing: The model has information encoded in its weights. It can tell you about Python syntax, email regex patterns, file handling best practices.
Doing: The model can actually read files, send emails, query databases, call APIs — not by generating code, but by invoking capabilities directly.
This distinction matters because “doing” scales. A model that knows about file operations helps one user at a time. A model that can do file operations helps thousands of users in parallel, efficiently.
The tools you expose via MCP determine what your agent can do. Design them well:
Instead of “write code that does X,” you prompt for intent:
The model decides which tools to call, not how to implement the operation.
MCP tools can be tested independently of the model. You can:
This is much cleaner than testing generated code output.
When models generate code, you’re trusting arbitrary execution. With MCP:
One pattern emerging from MCP is what Kaden called “code mode” — where LLMs generate structured tool calls rather than prose.
``` User: What meetings do I have tomorrow?
Model (code mode): calendar.list_events( start=“2026-03-18T00:00:00Z”, end=“2026-03-18T23:59:59Z” )
[Result: 3 meetings returned]
Model (prose mode): You have 3 meetings tomorrow:
The model seamlessly switches between generating tool calls and generating human-readable output. The user never sees the tool calls — just the result.
I believe we’re at the early stages of a fundamental shift in LLM architecture:
Phase 1 (past): LLMs as text completion engines Phase 2 (present): LLMs as code generators Phase 3 (emerging): LLMs as tool orchestrators
MCP is the protocol that enables Phase 3. And if the efficiency gains hold up at scale, there’s no going back.
If you’re building with LLMs today:
Start thinking in tools — What operations does your system need? Can they be exposed as MCP calls?
Design for invocation, not generation — Instead of asking “how do I get the model to write this code?”, ask “what tool should the model call?”
Invest in structured outputs — The more structured your tool responses, the better the model can reason about them.
Watch the ecosystem — MCP adoption is growing. The tools and patterns emerging now will define how we build AI systems for years.
The meetup ended with a packed Q&A session. Everyone wanted to know: how do I start using this? The short answer: start small. Pick one operation in your system. Expose it as a tool. See what happens.
The long answer is what we’re all figuring out together.
Thanks to Kaden Wilkinson for the presentation and to the Forge Utah Foundation for hosting. The conversations afterward about parking software parsers with Kyler Griggs and Bahram Movlanov were an unexpected highlight.