An AI application needs to read a catalogue, inspect a CRM record or open a support ticket. MCP can make those capabilities discoverable through a shared contract. But a successful connection proves only that messages crossed a boundary. It does not prove that the server is trustworthy, the model chose the right tool or the resulting action was authorized.
Start with the boundary: MCP is a connection contract
The Model Context Protocol (MCP) is an open protocol that standardizes how an application built around language models communicates with services exposing resources, prompts or tools.
It can matter when several AI hosts or teams need to discover and reuse the same bounded capabilities without rebuilding each connection. If there is one consumer and one stable workflow, a direct API call or fixed integration may be simpler.
The governing distinction is straightforward: MCP standardizes connectivity, discovery and invocation. It does not define business authority. Identity, permissions, approvals, credential handling, logs and revocation remain responsibilities of the application and the organization operating it.
What MCP means in the current specification
This guide uses MCP specification 2026-07-28, checked on 24 October 2026. Naming the version matters because many explainers still describe initialization, sessions and transports from older releases.
In the current specification, requests are self-contained and carry the necessary protocol, client identity and capability information. The July 2026 release removed the core handshake and session identifier, added server/discover, revised multi-round-trip behaviour and hardened the authorization architecture. Several earlier elements, including legacy HTTP+SSE, are deprecated for new implementations.
Those are specification facts, not evidence that every host, SDK or server already supports the same version. Product compatibility must be verified independently.
The three main roles translate into three business questions:
- Host: which application runs the experience, presents choices and applies policy?
- Client: which connector inside that host speaks MCP to this particular server, with which version and identity?
- Server: who exposes the capability, and which upstream systems or credentials does it use?
A server can expose:
- resources—data or context the application can load;
- prompts—reusable templates or workflows a person can select;
- tools—callable functions that can read information or create side effects.
The labels are technical, but the difference is operational. Loading a resource, choosing a prompt and invoking a tool create different consequences and deserve different controls.
Interoperability pays only when there is something to reuse
Consider a company with two approved AI hosts. Both need to read the same product catalogue and create support tickets. One maintained MCP server could expose a read-only catalogue resource and a tightly scoped ticket-creation tool. The value is not the MCP label. It is the ability to reuse a consistent capability across compatible consumers.
That value weakens when hosts interpret tools differently, descriptions change without review, the server lacks an owner or only one predictable consumer exists. MCP does not remove integration work. It moves part of that work into a common boundary that still needs design, versioning and maintenance.
Before adopting it, name the reuse:
- which hosts or teams will consume the capability;
- which resources or actions need consistent semantics;
- who will own the server, descriptions and compatibility;
- which duplicated integration work will actually disappear.
If those answers are vague, the protocol may be arriving before the interoperability problem.
MCP and APIs sit at different layers
An MCP server often calls an API, queries a database or invokes a local process behind the protocol. The API remains the contract with the business system. MCP gives an AI application a common way to discover and invoke the capability exposed above it.
This is why “MCP or API?” is often the wrong comparison. The practical choice is among:
- a reusable MCP boundary over existing systems;
- a direct API call controlled by one application;
- a fixed workflow where sequence and rules are not selected dynamically;
- no connection until scope and ownership exist.
An internal application that reads one status endpoint every morning and writes the same deterministic report does not need tool discovery. A scheduled API integration is easier to delimit, observe and test. MCP earns its place when cross-consumer discovery and reuse are genuine requirements—not when they merely add another layer.
MCP does not make an agent autonomous
Exposing a tool does not grant a model the business right to use it. The protocol can describe how a capability is discovered and called. The product and organization must still determine who may trigger it, which arguments are allowed, when confirmation is required and which effects are prohibited.
Nor does MCP automatically turn a chatbot or workflow into an agent. Whether an agent is appropriate depends on the path through the task, the need to choose among tools and the limits around that choice. AI agents: what they are and when to use them in business owns that broader decision.
The narrower question here is authority. If a system discovers a tool named create_ticket, can it select the customer, attach documents, set priority or submit without confirmation? The tool name does not tell you.
The M4TIC MCP value-and-authority map
This map is an M4TIC editorial synthesis, not a protocol feature. It checks connection value and, separately, the authority crossing the boundary.
1. Connection value
Question: which repeated integration problem does MCP remove?
Minimum evidence: named hosts, tools and reuse cases; an explicit comparison with a direct API or fixed workflow.
2. Discovery surface
Question: which resources, prompts and tools can the client discover, and who can change their descriptions or behaviour?
Minimum evidence: an allowlisted catalogue, verified provenance, version or change review and unnecessary capabilities removed.
3. Identity and credentials
Question: whose identity reaches the MCP server and the upstream service?
Minimum evidence: separate user, workload and server identities; token audience validation; appropriate credential storage and separation; no prohibited token passthrough.
4. Effective authority
Question: what can the capability read, change, send, delete or trigger?
Minimum evidence: least-privilege scopes, application policy, test accounts and bounded data or action domains.
5. Approval and execution
Question: where can a material action be denied, confirmed or escalated?
Minimum evidence: understandable UI, consent tied to the server and action, and deterministic approval before consequential side effects.
6. Evidence and exit
Question: what is recorded, and how can the connection actually be disabled?
Minimum evidence: logs for actor, server, tool, arguments, result and outcome; an operational owner; an incident path; and a tested disable, revoke and removal procedure.
Technical authorization does not settle these layers. Even a correctly implemented OAuth flow does not decide whether an action is appropriate for that role, customer or moment.
Where risk enters the connection
MCP is neither a security guarantee nor the sole cause of the risks around it. It does create a boundary where descriptions, data, tools and credentials can influence one another.
Four control areas deserve attention:
- Server provenance: who publishes and updates the server, and how is it verified before use?
- Untrusted content: resources and tool descriptions can contain instructions or framing that influence model behaviour.
- Credentials and permissions: a harmless-looking tool can inherit access far broader than its name suggests.
- Incomplete audit: recording that “a tool was called” is insufficient when identity, arguments, result, effect or approval are missing.
Current MCP guidance emphasizes token audience, credential separation, least privilege and the prohibition of token passthrough in relevant authorization flows. Those controls are necessary where they apply. They are not proof that the complete business system is governed.
If sensitive company data crosses the connection, deployment location is only part of the question. Private AI for business covers exposure and data boundaries; private deployment does not replace authorization or audit.
Local and remote servers create different trust boundaries
A local server launched over stdio is an ordinary process on the device. MCP does not turn it into a sandbox. It may inherit the operating-system account’s access, read files or environment variables available to the process and introduce provenance or supply-chain risk. “Local” does not automatically mean “contained.”
A remote server introduces network identity, authorization, token management, service availability and trust in the operator. It may be easier to administer centrally, but it is not automatically safer.
The useful question is not which category wins in the abstract. Ask: which process or service runs the code, with which credentials, over which data, under whose control and with what revocation path?
Four decisions—not an adoption race
Use MCP now
Choose it when several compatible hosts, teams or applications need the same bounded capabilities and ownership, provenance, identity, approval, logging and revocation are already defined.
Run a bounded pilot
Choose a pilot when reuse looks plausible but client support, tool semantics or operational responsibility still need evidence. Start with read-only access or low-authority actions, limited data and a real exit path.
Use a direct API or fixed workflow
Choose the simpler connection when there is one consumer, a predictable sequence and a stable contract. Lower flexibility can mean a clearer boundary and easier audit.
Do not connect yet
Stop when need, provenance, data, permissions, approval or accountable ownership are undefined. An unverified third-party local server asking for broad filesystem and environment access is not a harmless trial. It is a connection without a control model.
Make the first step small and revocable
A useful first experiment does not measure how many functions can be exposed. It tests whether one bounded capability retains its meaning, limits and evidence through the full path.
Define one use case, one owner and one observable result. Grant the minimum privilege. Separate identities. Require visible approval before a material effect. Record the request, tool, arguments, approval, result and outcome. Then disable the server and revoke its credentials. A revocation path that has never been tested is only an intention.
When the pilot moves from connection design to operational behaviour, it needs test cases, limits, escalation and recovery. How to test an AI agent before launch covers that next step without turning this article into a testing framework.
MCP deserves a place when interoperability is real and authority remains explicit. If its value rests mainly on the novelty of the protocol—or nobody can describe what the connection can actually do—the better decision is to simplify or stop.
Sources and further reading
Primary guidance behind this article.
- Model Context Protocol Specification — 2026-07-28Model Context Protocol
Current verified definition of protocol roles, capabilities, requests and security principles.
- The 2026-07-28 SpecificationModel Context Protocol Blog
Official release notes for the stateless core, authorization, extensions and deprecations.
- Authorization — 2026-07-28Model Context Protocol
HTTP authorization roles, discovery and least-privilege guidance.
- Authorization security considerationsModel Context Protocol
Normative guidance on token audience, storage, validation, redirects and token passthrough.
- Security best practicesModel Context Protocol
Official implementation guidance on consent, scopes, proxies, SSRF and local compromise.
- Local server securityModel Context Protocol
Guidance on local-process trust, supply-chain exposure, tool catalogues and containment.
- Model Context Protocol: Security Design Considerations for AI-Driven AutomationNSA Artificial Intelligence Security Center
Public guidance published 20 May 2026 on trust boundaries and dynamic tool invocation.