MCP in practice: connect an agent without handing it the keys
What Model Context Protocol standardizes, what your application still needs to enforce, and how to design a useful first integration.
Revised September 4, 2026. Protocol details below refer to the 2025-06-18 specification.
Model Context Protocol gives AI applications a common way to connect to external capabilities. It can reduce repeated integration work, but it does not decide which business actions an agent should be allowed to take.
That distinction matters when the connected system contains customer records, operational data, or actions that cannot easily be undone.
What connects to what?
In MCP's architecture, the host is the AI application. It manages clients, each connected to a server that exposes capabilities. A server might expose searchable documents, a reusable prompt, or a tool that looks up an order.
The host manages the interaction; a server does not need the entire conversation to fulfill a narrow request. The protocol supports capability negotiation, so integrations must account for what both sides actually implement. See the MCP architecture specification.
Two standard transports, different deployment choices
The 2025-06-18 specification defines stdio and Streamable HTTP. With stdio, the client launches a server subprocess and exchanges messages through standard input and output. With Streamable HTTP, the server runs independently and clients communicate over HTTP; SSE may be used for streaming.
Streamable HTTP replaced the older HTTP+SSE transport. That does not make SSE itself obsolete or inherently insecure. A stateless HTTP deployment is a design choice, not a third standard transport. See the transport specification.
Launching a subprocess does not automatically sandbox it. Review which files, credentials, and network destinations the process can access. Container boundaries also depend on configuration; host mounts or excessive privileges can expose more than intended.
Design the business boundary first
Suppose your team wants an assistant to investigate delayed deliveries. This is an illustrative integration design, not a complete server implementation.
Start with a narrow read operation: find an order the authenticated user is entitled to see and return its status, relevant timestamps, and source identifiers. Avoid a general-purpose database or shell tool when a specific operation will do.
Then separate possible actions:
- Read an order's status.
- Draft a customer update.
- Send the approved update.
- Change the delivery assignment.
Those operations have different consequences. Do not bundle them behind one broadly privileged tool just because they belong to the same workflow.
Authorization must be checked when the operation executes. A customer ID supplied by a model is a requested target, not proof that the user owns that record. An approval prompt in the interface is useful, but the backend still has to enforce the decision.
What MCP does not implement for you
You still need input validation, tenant isolation, limits, timeouts, and a plan for partial failure. A protocol-compatible server can implement a business operation incorrectly.
For a write operation, decide how retries work before enabling them. If the downstream service accepted a change but the response was lost, blindly repeating the request may duplicate its effect. Return durable operation identifiers and provide a way to inspect the actual result.
Keep credentials out of model-visible text and routine logs. For authenticated remote integrations, validate the intended audience of credentials; do not simply pass a client's token through to an unrelated downstream service. MCP's security guidance explicitly warns against token passthrough. Read the security guidance.
A useful first integration test
Test the workflow with a permitted record, a forbidden record, missing data, and a temporarily unavailable dependency. Verify that denied access remains denied even if the request is phrased differently.
For actions, test duplicate submissions and a timeout after the downstream change has succeeded. The user should see what is known, what is uncertain, and how to recover — not an invented success message.
Log enough to reconstruct the operation: identity, tool, target, authorization outcome, and result. Redact sensitive payloads and define retention instead of recording every argument and response indefinitely.
MCP is a connection mechanism. The quality of the integration still comes from a well-defined operation and controls around it.
Next: how Skills complement MCP and security boundaries for agents.