MCP is plumbing. Good plumbing matters, but nobody buys a building because the pipes support a fashionable protocol.
Model Context Protocol gives AI applications a standard way to discover tools, read structured context and call actions. That can reduce the number of one off integrations a team has to maintain. It can also make permissions and tool definitions easier to inspect across different agent clients.
None of that answers the business question: what work should the agent complete?
What changed in the 2026 specification
The 2026 MCP work moved the protocol closer to production infrastructure. The July 2026 specification release candidate introduced a stateless core, an extensions framework, long running Tasks, stronger authorization requirements and a formal deprecation policy.
Those changes matter because real work is not always one request followed by one response. A task may wait for an external system, require approval, or need to be cancelled and resumed. The Tasks extension provides a lifecycle for that work. Authorization hardening also brings the protocol closer to normal OAuth and OpenID Connect deployments.
The result is better infrastructure for agents that have to operate across time and tools. It is not a finished operating model.
MCP standardizes access, not judgment
An MCP server can expose a tool such as:
- search approved customer records
- create a draft opportunity in a CRM
- retrieve a document from a case
- request a calendar hold
- check the status of an internal job
The protocol can describe the tool and carry the request. It does not determine whether the agent should use it in this situation, whether the information is complete, or whether the action needs approval.
Those decisions belong in the system design.
The safest tool is a narrow tool
Avoid giving an agent broad database or browser access when the role needs one defined action. A tool called update_record is difficult to govern. A tool called add_qualification_note can validate the record type, allowed fields and caller identity before anything changes.
Useful controls include:
- A named identity. Every tool call should belong to a system or user identity that can be audited.
- Least privilege. The tool should expose the smallest useful action and the smallest data surface.
- Validation before writes. Inputs should be checked outside the language model before a system changes.
- Approval for consequence. Financial, customer facing or policy actions should stop at a review point where required.
- Traceable outcomes. The operation should record what was requested, what the tool returned and what changed.
This is why “we use MCP” is not a service proposition. “We connect an onboarding agent to the approved records and actions it needs, with review before account activation” is.
When MCP is the right connection layer
MCP is useful when the same capability needs to be available to several agent clients or when a team wants a stable, discoverable boundary around internal tools. It is also helpful for long running work where task state must be checked or cancelled.
It may be unnecessary when:
- one deterministic workflow calls one existing API
- a fixed integration already has mature authentication and observability
- the agent only needs read access through a controlled retrieval layer
- exposing another server would add operational cost without reuse
Standards reduce integration friction. They do not remove the need to choose the simplest architecture that can safely finish the work.
What a buyer should ask for
Do not ask whether an agency “supports MCP.” Ask for the connection map:
| Question | What a clear answer should show |
|---|---|
| Which systems can the agent reach? | A named list, not “all your tools” |
| Which actions can it perform? | Specific read and write operations |
| How is access granted? | Identity, scopes and secret handling |
| Where does approval happen? | A visible pause and responsible person |
| What is recorded? | Inputs, tool calls, results and changes |
| How does the task recover? | Retry, cancellation and handoff behavior |
The protocol is an implementation choice. The product is a dependable piece of work moving through the business with the right boundaries.