The Model Context Protocol, or MCP, is an open protocol that lets an AI application connect to servers exposing tools, resources and reusable prompts through a standardized client-server interface.
Teams can mistake a common connection protocol for a complete agent platform or security boundary. MCP can standardize discovery and invocation, but the application still owns user identity, authorization design, tool safety, business policy, result verification, observability and recovery.
MCP is most useful as an integration contract. It reduces bespoke connector work and allows clients and servers to evolve independently. Production quality still depends on the narrower contracts, permissions and operating controls placed around each exposed capability.
Architecture
MCP standardizes the connection, not the whole application
An MCP host is the AI application in which the user works. It creates one or more clients that connect to MCP servers. A server advertises capabilities such as tools, resources and prompts. Protocol negotiation lets the participants agree on a supported version and capabilities before those features are used.
The distinction between features matters. Resources expose context that the application can read, tools allow the model to request an operation, and prompts provide reusable interaction templates. The host decides how these capabilities appear to the model and user. Business workflow, memory and final authority can remain outside the protocol.
| Component | Primary job | Control question |
|---|---|---|
| Host | Runs the AI experience and coordinates clients | Which user and policy govern the interaction? |
| Client | Maintains a protocol connection to one server | Which capabilities are accepted and exposed? |
| Server | Adapts data or actions into MCP capabilities | What system and authority sit behind it? |
| Resource | Provides context for the application to read | How is sensitive content scoped? |
| Tool | Offers an operation the model may request | What validates and approves the effect? |
Production
Enterprise adoption needs controls above and below MCP
Above the protocol, the host needs user consent, policy, approval, model evaluation and a clear display of proposed actions. Below it, the server and target system need authentication, scoped authorization, argument validation, safe transactions, logging and reconciliation. Neither side should assume that a well-formed protocol message is an authorized business instruction.
Treat third-party servers as software dependencies with access. Review their publisher, code or service controls, data handling, update path and incident response. Maintain an inventory of connected servers and capabilities. A protocol makes integration portable, which also makes controlled onboarding and removal more important.
- Bind tokens to the intended audience and never pass them through casually.
- Expose the smallest capability set required for the user and workflow.
- Confirm consequential tool calls before execution.
- Sanitize logs while retaining enough detail for audit and recovery.
- Re-evaluate behavior whenever tools, schemas, servers or models change.
What good looks like
Useful outcomes from Model Context Protocol
- Engineering can connect compatible AI clients and business capabilities through a shared protocol surface.
- Tools, read-oriented resources and reusable prompt templates remain distinguishable in the architecture.
- The organization evaluates an MCP server by its authority, data path and implementation rather than the protocol label alone.
- Version negotiation and capability discovery become explicit integration concerns.
- Agent workflows retain application-level approval, audit and recovery around consequential actions.
Operating model
How to run the work
- 01
Define the business capability
Start with the exact information or action the AI application needs. Describe the user, system of record, permitted scope and observable outcome. Decide whether the capability belongs as a resource to read, a tool to invoke or a prompt template to reuse.
- 02
Choose client and server boundaries
Identify which host controls the conversation and permissions, which MCP client maintains the server connection and which server adapts the underlying system. Keep trust boundaries and deployment ownership visible rather than treating every server as an interchangeable plugin.
- 03
Constrain and validate the interface
Use narrow operations, typed arguments, least-privilege credentials and explicit error states. Validate model-generated inputs against business rules. Separate read access from mutations and require approval before effects that are costly, external or hard to reverse.
- 04
Test protocol and business behavior
Test capability discovery, version compatibility, authorization, malformed requests, timeouts and partial failures. Then evaluate whether the agent chooses the right capability, supplies correct arguments and verifies the result in realistic and adversarial cases.
Evaluation
Questions that change the decision
- Should the capability be represented as a tool, a resource or an application-owned workflow step?
- Where are user identity and authorization enforced for each server and downstream system?
- Can a write operation be made idempotent and reconciled when its response is ambiguous?
- Which server metadata and tool descriptions are trusted as instructions by the AI application?
- Who reviews server updates, protocol versions and newly exposed capabilities?
Failure modes
Where teams lose control
A broadly described tool can give the model more authority than the user’s task requires.
Untrusted resource or tool output can contain instructions that attempt to redirect model behavior.
Token forwarding or weak audience validation can expose credentials beyond their intended server.
A compatible server can still implement unsafe writes, poor isolation or inadequate audit records.
Protocol success can be confused with business success when the final system effect is not reconciled.
Measurement
Measure the finished job
Measure the completed workflow, including review effort and exceptions. Output volume on its own is not evidence of a better process.
- successful capability discovery and version negotiation by supported client
- tool calls rejected for invalid arguments, permissions or business policy
- end-to-end action success after reconciliation with the system of record
- duplicate effects prevented after retry or timeout
- security and regression cases passing for each server release
Questions
Common questions
Is MCP an API?
MCP is a protocol for how AI applications and capability servers discover and exchange tools, resources, prompts and related messages. A server may adapt existing APIs, databases or local functions behind that protocol. MCP does not replace every underlying business API.
What is an MCP server?
It is a program or remote service that exposes capabilities through MCP. The capability may read data, provide a reusable resource or perform an action. Its safety depends on the implementation, credentials and target systems as well as the protocol.
Does MCP make AI agents secure?
No protocol label provides that guarantee. MCP defines interoperable connection behavior and includes authorization mechanisms for applicable transports. The host, server and organization must still enforce identity, least privilege, approval, input validation, isolation, audit and recovery.
Sources
Primary references
- MCP architecture overview Model Context Protocol
- MCP security best practices Model Context Protocol
About the author
Tony Kim
Tony writes about applied AI, dependable product engineering and the systems that turn complex response work into controlled delivery.
Zeke
AI product engineering for moving a software brief into a reliable production product.
Product leaders, founders and engineering teams. Start with the workflow, constraints and evidence you already have.
See Zeke→