Standardize how agent hosts discover and invoke external capabilities while keeping trust, authorization, and business policy explicit.
MCP defines a protocol boundary between an application hosting an agent, its protocol clients, and servers exposing capabilities such as tools, resources, and prompts. It reduces custom integration plumbing; it does not make a server trustworthy or decide whether a proposed business action is authorized.
Treat discovery metadata and tool results as external input. The host still owns user intent, capability selection, approval policy, and result handling. Pin the supported protocol version and test the capabilities actually negotiated: a common envelope cannot guarantee identical semantics across independently implemented servers.
A proof of concept may connect one trusted local server and inspect tool results manually; record which capabilities and transport assumptions it relies on.
Production requires server registration, schema validation, scoped credentials, operation timeouts, and explicit approval rules for mutating tools before enabling discovery broadly.
Enterprise scale adds server ownership, version compatibility testing, per-tenant connection policy, capacity limits, and auditable capability changes across many teams.
Owns user interaction, model context, tool policy, and approval boundaries.
Negotiates capabilities and manages the transport lifecycle for a server connection.
Exposes approved capabilities and validates incoming requests before calling downstream systems.
Enforces identity, audience, scope, resource access, and operation policy independently of model output.
Records tool version, sanitized inputs, result status, and downstream operation identifiers.
flowchart LR
H["Agent host"] --> P["Host tool policy"]
P --> C["MCP client"]
C --> S["Registered MCP server"]
S --> A["Downstream authorization"]
A --> E["Enterprise API"]
S --> V["Untrusted result validation"]
V --> HResolve the server from an administratively controlled registry with an owner and supported protocol version.
Initialize the connection and record available capabilities; reject unsupported requirements rather than assuming every server behaves identically.
Establish transport-appropriate credentials and downstream resource policy; never equate successful connection with permission for every tool.
Check the chosen tool, argument schema, resource scope, deadline, and any required action approval before sending the request.
Validate result shape, preserve provenance, and treat returned text as evidence rather than new governing instructions.
For mutations, retain a stable operation identifier and query uncertain downstream outcomes before considering a retry.
Enterprise software · Illustrative enterprise scenario, not a reported customer outcome.
Illustrative architecture: A support assistant needs governed access to product documentation and customer case summaries through separately owned integrations.
Custom adapters duplicate connection logic, but broad connector credentials would expose unrelated customer cases.
Provide interoperable discovery while enforcing customer assignment and read-only access for this workflow.
The host connects only to registered servers; a case service rechecks the authenticated support user's tenant and case scope.
A server advertises a new write tool; host policy withholds it until the owner reviews its schema and action semantics.
Measure integration maintenance effort, denied unauthorized requests, tool error rate, and evidence correctness; interoperability alone does not establish safety or quality.
| Decision | Benefit | Cost |
|---|---|---|
| Standard protocol boundary | Reduces repeated connector plumbing. | Still requires server-specific semantic and security review. |
| Dynamic capability discovery | Allows integrations to evolve without hardcoding every tool. | Unexpected metadata changes need policy gates and compatibility checks. |
| Remote server transport | Centralizes connector operations and updates. | Introduces network latency, identity management, and availability dependencies. |
Detect: Result handling detects an attempted action outside the authorized task and tool scope.
Recover: Treat the text as untrusted evidence, block the action, and record the offending server response.
Detect: The host has a submitted operation identifier but no confirmed result.
Recover: Query the business system through a safe status path before retrying with the same logical operation key.
Review server ownership, downstream access, and mutation semantics separately.
Use scoped, audience-bound credentials and enforce resource authorization at the service boundary.
Keep discovery content in an untrusted data channel and apply host-owned capability policy.