Connecting AI systems with MCP

If an AI host connects calendars, issue trackers, and file systems through separate proprietary plugins, each product reimplements discovery, schemas, permissions, and error handling. MCP standardizes the messages and capability representations exchanged over these connections, making it easier to combine hosts and servers. Actual scheduling rules and issue permissions remain owned by each domain service.

The success criteria for adopting MCP therefore go beyond having fewer connectors. Even when the server revision changes, the host must negotiate capabilities, unauthorized resources must stay invisible, and tool failures must reach the user in a recoverable state. Continuing to use existing REST APIs and queues inside the server is also a normal design; keep the protocol boundary distinct from the domain boundary.

When a desktop host connects to a local file server and a remote CRM server, those servers have different trust levels. A local process's installation package may also be tampered with, while remote servers pose network and token-leakage risks. The host must check the server's tool descriptions against the targets and actions the user allowed, rather than treating those descriptions as trusted policy.

The client manages more than a simple network socket. It must bind the negotiated protocol version, supported capabilities, outstanding requests, and cancellation signals to the session. After a disconnect, a new session may not know whether an earlier request actually ran, so state-changing tools must allow results to be queried again using an operation identity issued by the server.

Internal policy documents can be provided as resources so the host selects the parts it needs, while a weekly-report format can be a user-selected prompt. Creating an actual ticket is a tool action. Distinguishing these three lets information to read, actions to execute, and templates explicitly started by users have different consent mechanisms and UIs.

Classifying by name alone is risky. If calling `previewInvoice` increments a view counter or creates a temporary row, treat it as a tool with side effects. Resource URIs must also respect the current user's tenant and permissions, and prompt instructions may contain untrusted external text. Verify each primitive's data sources and execution effects with contract tests.

The next action depends on whether the transport disconnected, the JSON message was invalid, or the tool input violated business rules. In the first case, recover the same session or query the result; in the second, check client and server versions; in the third, the user must correct the input. A single “failure” string leaves these decisions to model guesswork.

State-changing requests such as payments or deletions, in particular, must not treat a timeout as a failure, because the server may commit the change and lose only the response. Reusing the client-generated idempotency key for the same business operation and checking the final result through a status endpoint resolves the uncertainty without duplicate execution.

A token must be evidence of delegated authority with a specific audience, scope, and expiry, not a master key copying all of a user's permissions. If an MCP server passes a token it received directly to another service, that token can be used on resources it was never intended for. The server must separately exchange tokens for the downstream services it needs and recheck the subject-resource relationship on every call.

Instead of indiscriminately storing the entire prompt, record who acted, which client and tool revision they used, the target, approval and policy results, and the state change produced. Link sensitive inputs through hashes or de-identified identifiers and control access to the originals separately. This structure lets you reconstruct actions during an incident while limiting personal-data retention.

A fictional inventory server changes a required lookup argument from productId to sku. Connection and discovery succeed, but the existing client call no longer matches the schema. Include an existing client with cached old schemas. An updated server list does not guarantee that an already-running task knows the new contract.

Separate fixtures for the original request and a converted request. If conversion is needed, record ownership and ID-mapping rules rather than assuming that renaming a field preserves meaning. Check whether product IDs and SKUs map one-to-one or vary by variant. Unconvertible inputs need explicit errors, not guesses that could retrieve the wrong product.

Automatically replacing a missing inventory count with an empty string or zero can falsely imply out-of-stock. Treat a missing required field as a contract failure and stop it before purchase decisions. Also include a legitimate zero-quantity result. Distinguishing an explicit zero from an absent field supports different actions for out-of-stock and contract failure.

Keep protocol revision, discovered schemas, converter version and fixture results in the approval record. Rerun the bundle after server updates to detect failures invisible to connectivity checks. Record a review reason when discovered schemas differ from approved ones. Distinguish optional additions from required semantic changes to avoid unnecessary total shutdown.

A teaching fixture supplies a token with the same user and a valid signature but a different intended resource. The MCP server must reject it before tool execution rather than accepting it because the username matches. Verify that the underlying tool was never called after rejection. A correct error status is insufficient if data was queried before the access check.

A second fixture uses the correct resource token to request another tenant’s order. Token audience and domain-object ownership are separate checks; passing only one must not return the data. Separate fixtures prevent mistaking audience validation for complete authorization. Record which user, scope or ownership value changed.

Record rejection-reason categories, resource identifiers, and policy revisions in the audit log. This makes it possible to identify which boundary rejected a request without copying raw tokens or personal order data. Use rejection codes that operators can reproduce and anonymous request IDs. Retaining credential bodies that are not needed to diagnose a failure turns diagnostic data into another credential store.

This section concerns remote authorization boundaries. Do not assume local stdio and remote HTTP use identical credential handling; check the documentation for the selected transport and protocol revision. Record the actual transport in deployment documents rather than inheriting another example’s security assumptions. Recheck trusted actors and credential lifetimes when the connection context changes.

Place a valid paragraph and an external-transmission instruction together in a fictional document-tool result. The pass condition is that the valid paragraph may support an answer, but the transmission instruction does not authorize any new tool execution. Even when using a safe evidence paragraph, link its source ID in the answer. Rejecting the injected instruction does not automatically verify the accuracy or freshness of the remaining paragraphs.

One fixture returns permission denied and another returns genuinely zero search results. Check distinct guidance and retry policies to detect empty-array conversions that hide errors. Check that permission denial does not trigger an automatically broader search. Seeking inaccessible material through another tool still needs separate authorization.

Remove a required field from a normal result and verify that host validation stops processing. Fluent guesses for missing values merely disguise the error; they do not restore the task contract. Test responses containing valid values alongside responses containing empty strings. A property name alone does not establish a usable value; distinguish structural success from semantic failure.

The final trace links the requested tool, validated result type, rejected follow-up action, and state reported to the user. This record explains how the connection layer can succeed while business judgment fails. After policy changes, rerun old attack fixtures and normal document fixtures together. A higher rejection rate does not satisfy the integration's functional requirements if the material needed for normal questions is also blocked.