TL;DR
- MCP is one of the most important pieces of AI infrastructure right now because it lets models work directly with real business systems.
- The same connection layer creates new risks, including tool poisoning, indirect prompt injection, excessive permissions, and supply-chain exposure.
- Tool definitions themselves can contain instructions the model may follow, even when the user never sees them.
- More connected tools can also consume context, increase latency, and make tool selection harder if the stack is not designed carefully.
- The most important operational risk may be simpler: the AI fails to query a required source and still produces a confident answer.
- The goal is not to avoid MCP. The goal is to make the connections observable, restricted, and auditable.
1. The Answer Looked Perfect
This is the failure that matters.
Ask an AI system:
“How did last quarter look?”
It checks the CRM.
It writes a polished summary.
The numbers seem reasonable.
The explanation sounds finished.
There is only one problem.
It never checked billing.
And nothing in the final answer tells you that.
That is a very different problem from an obvious error message.
An obvious failure stops the workflow.
A confident incomplete answer can drive a decision.
As we give AI access to more business systems, this distinction becomes critical:
A confident answer is not the same thing as a queried answer.
2. MCP Makes AI More Useful Because It Gives It Access
MCP, or Model Context Protocol, solves a real problem.
Instead of copying data into ChatGPT or Claude, you can connect the model directly to systems such as:
Google Ads.
Search Console.
Your CRM.
Analytics.
Documents.
Databases.
Infrastructure.
That is why we are bullish on MCP.
The AI stops being a box you talk to and starts becoming a layer that can interact with the systems where the work actually happens.
But the exact thing that makes MCP powerful also creates the risk.
The model can now reach farther.
And it can reach farther when it is wrong.
3. A Tool Can Lie to the Model
One of the stranger MCP security issues is called tool poisoning.
An MCP tool publishes a description explaining what it does and how the model should use it.
The user may see a simple tool name.
The model sees the underlying description.
Now imagine someone hides another instruction inside that description:
Read a sensitive file.
Send the contents somewhere else.
Change the parameters.
Do something the user never requested.
From the model’s perspective, that text can still look like an instruction.
Researchers have already demonstrated this attack, and testing across live MCP tools has shown that some models can be surprisingly susceptible.
This is one of those cases where normal software security scanning is necessary but not sufficient.
The dangerous part might not be executable code.
It might just be a sentence.
4. The Bigger Business Risk Is Silent Failure
Security gets more attention.
Operational reliability may matter more day to day.
An agent can:
Call the wrong tool.
Skip a required tool.
Use the wrong date range.
Get zero results.
Receive partial data.
Or encounter a server that is unavailable.
Then it can still write the report.
That is the part businesses need to design around.
For important workflows, we want the system to record things like:
Which tools were called.
Which sources were expected.
How many records came back.
Which calls failed.
Whether a required source returned nothing.
If billing failed, the quarterly report should not quietly become a CRM report.
It should say the report is incomplete.
That sounds obvious.
Most impressive AI demos do not show this part.
5.More Connections Are Not Automatically Better
There is another cost to connecting everything.
Tools take up context.
In some agent systems, connecting a large number of MCP servers can load a large number of tool definitions into the model before the actual work even begins.
That means more tokens, more latency, more choices for the model, and potentially worse tool selection.
Modern systems are getting better at loading tools only when needed, but the principle remains:
Do not connect twenty tools because twenty integrations are available.
Connect the tools the workflow actually needs.
The goal is not maximum connectivity.
The goal is reliable work.
Read the full article: There Is A MCP for That. Here Is What That Actually Costs. →
The full article covers tool poisoning, hosted versus self-hosted MCP servers, supply-chain risk, indirect prompt injection, context-window costs, silent failures, and how we would structure MCP access inside a real business..
6. How We Would Approach MCP in a Business
We would still use MCP.
Especially for read-heavy workflows such as reporting, research, analytics, CRM lookups, and infrastructure checks.
But we would start narrow.
Read access before write access.
Limited permissions before broad permissions.
A small number of reviewed servers instead of a pile of community integrations.
Logging around important tool calls.
Human approval around high-impact actions.
And for critical reports, we would make missing data visible instead of letting the model quietly work around it.
MCP is not the problem.
Uncontrolled access is.
Final Thought
The first wave of AI was about getting better answers.
The next wave is about giving AI access to the systems where the business actually runs.
That is a much bigger deal.
It is also where the stakes change.
When AI only writes text, a mistake gives you bad text.
When AI can read databases, update customer records, send messages, pull financial data, and interact with production systems, a mistake can become an action or a decision.
So yes, there is an MCP for that.
The better question is:
What happens when that connection fails, lies, or gives the model only half the story?
Connection is the easy part.
Trust is the architecture.
Thanks for reading Signal Over Noise,
where we separate real business signal from AI noise.
where we separate real business signal from AI noise.
See you next Tuesday,
Avi Kumar
Founder: Kuware.com
Subscribe Link: https://kuware.com/newsletter/