MCP Integration: Roles, Permissions and Version Boundaries

Reviewed and updated October 8, 2026.

Model Context Protocol, or MCP, provides a shared interface for connecting AI applications to resources and tools. Use it when a maintained protocol boundary can reduce repeated connector work across hosts. A direct API integration may be simpler when one application needs one stable operation.

This article uses the 2026-07-28 protocol revision, checked in October 2026. Pin the revision supported by your host, client and server. Earlier examples may use lifecycle or connection assumptions that changed between revisions.

Know which component owns the behavior

The MCP architecture separates a host application, clients and servers. The host coordinates model use, consent and context. Each client communicates with one server. Servers expose focused capabilities through resources, tools and prompts. In this revision, requests carry their protocol version and capabilities.

Resources expose context that a client can read. Tools expose named operations with schemas. A prompt template can structure an interaction, but none of these primitives establishes permission to read a particular customer record or change its state.

An illustrative read-only connector

Suppose two internal assistant applications need approved product procedures. This is a proposed integration, not an interoperability test result. Begin with a server exposing a procedure resource and a search tool over one approved collection.

The host obtains the user's authorization context through trusted identity infrastructure. The server enforces document access and returns source identifiers, versions and explicit errors. The host decides which returned evidence enters model context and how citations are displayed. It records the connector version with the request trace.

Test both hosts against the same resource and tool behavior, including pagination, missing resources, access denial and unsupported capabilities. A matching schema does not ensure matching user consent, output rendering or error handling.

Keep authorization at the actual boundary

Inspect local and remote deployments separately. Installing a local server involves trusting executable code and its environment access. A remote service requires transport, credential and audience handling appropriate to the deployment.

The current MCP security guidance covers consent, token audience and token passthrough risks. A server must not accept a token issued for another resource and simply forward it downstream. Application tools still need tenant, object and action checks outside the model.

Compare MCP with a direct integration

Choose MCP when several supported hosts need the same governed capability and someone owns compatibility updates. Choose a direct API client when it avoids an unnecessary adapter and makes authorization or error handling clearer. Both choices need versioning, tests, secrets handling and an operator.

Start with read-only access. Add a write tool only after defining its permitted targets, exact approval behavior, duplicate handling and audit records. Avoid exposing a generic shell or arbitrary HTTP tool merely because it makes the connector flexible.

For connecting business systems, see system integration. Request a project review with the hosts, sources and operations that would share the connector.