Mar 1, 2026 · Lab notes · 5 min

MCP and the interface between agents and tools

MCP provides a shared interface between AI applications and external tools and data. Its value is practical: a reusable integration boundary can reduce repeated adapter work. Protocol adoption does not establish universal compatibility, safety, or the quality of the resulting application.

The problem MCP solved

Without a shared interface, a team may implement a separate adapter for each application-service pair. The diagram below illustrates three applications and three services, rather than measuring an actual deployment. A protocol can reduce repeated interface work, but authentication, service semantics, permissions and testing still need implementation.

graph LR
  C1[Claude] --- T1[Postgres]
  C1 --- T2[Slack]
  C1 --- T3[GitHub]
  G1[GPT] --- T4[Postgres]
  G1 --- T5[Slack]
  G1 --- T6[GitHub]
  Ge[Gemini] --- T7[Postgres]
  Ge --- T8[Slack]
  Ge --- T9[GitHub]

  style C1 fill:#e8e8e8,color:#0a0a0a,stroke:#0a0a0a
  style G1 fill:#e8e8e8,color:#0a0a0a,stroke:#0a0a0a
  style Ge fill:#e8e8e8,color:#0a0a0a,stroke:#0a0a0a
          

graph LR
  C2[Claude] --> MCP{MCP}
  G2[GPT] --> MCP
  Gm[Gemini] --> MCP
  MCP --> S1[Postgres]
  MCP --> S2[Slack]
  MCP --> S3[GitHub]

  style MCP fill:#e8e8e8,color:#0a0a0a,stroke:#0a0a0a
          

Anthropic introduced MCP on November 25, 2024. The interface separates application clients from servers that expose capabilities. Compatibility depends on the negotiated protocol version and supported capabilities; a conforming implementation need not support every optional feature. The connection count below is an architectural illustration, not a measured reduction in engineering effort.

Architecture in sixty seconds

MCP follows a client-server model with three roles. Hosts are the user-facing applications (Claude Desktop, VS Code, an IDE plugin). Clients live inside hosts and maintain 1:1 connections with servers. Servers expose capabilities: tools agents can invoke, resources they can read, and prompts that provide templated workflows. Communication happens over JSON-RPC 2.0, and the protocol is bidirectional. Servers can request LLM completions back from the client through a feature called sampling.

graph LR
  User((User)) --> Host
  subgraph Host["Host (Claude Desktop / VS Code)"]
    direction TB
    LLM[LLM Engine]
    ClientA["Client A"]
    ClientB["Client B"]
    ClientC["Client C"]
    LLM --- ClientA
    LLM --- ClientB
    LLM --- ClientC
  end
  ClientA <-->|"JSON-RPC 2.0
stdio"| ServerA["MCP Server
Filesystem"]
  ClientB <-->|"JSON-RPC 2.0
HTTP"| ServerB["MCP Server
Postgres"]
  ClientC <-->|"JSON-RPC 2.0
HTTP"| ServerC["MCP Server
GitHub"]

  ServerA -.-|"sampling"| ClientA
  style Host fill:none,stroke:#0a0a0a
  style LLM fill:#e8e8e8,color:#0a0a0a,stroke:#0a0a0a
          

Streamable HTTP replaced the earlier HTTP+SSE transport in the March 26, 2025 changelog, not in June. The pinned June transport specification retains both stdio and Streamable HTTP. HTTP servers may use SSE for streaming. Session IDs are optional; when assigned, they must be globally unique and cryptographically secure. Load balancing and recovery remain implementation concerns.

The capability surface

MCP servers expose tools, resources and prompts. Tools perform operations; resources expose readable content; prompts provide templates. The June 18, 2025 changelog added structured tool output and resource links in tool results. It does not require every response to contain a REST-style _links object. An output schema can improve validation, but neither correctness nor a reduction in token use follows automatically.

Sampling allows a server to request model generation through the client when that capability is supported. The client retains control over the request. Elicitation requests additional user information. These capabilities need their own permission and review design; neither is a substitute for authorization of an external action.

Security: OAuth 2.1 and the trust model

For HTTP-based implementations that use authorization, the June 2025 authorization specification defines an OAuth-based framework. MCP servers act as resource servers and discover authorization-server information through metadata. The sequence diagram is a simplified authorization-code flow with PKCE. Token validation, scope design and approval of sensitive tool operations still require correct implementation.

sequenceDiagram
    participant U as User
    participant C as MCP Client
    participant A as Auth Server
(Okta / Auth0)
    participant S as MCP Server

    C->>A: Authorization request + PKCE
    A->>U: Consent prompt
    U->>A: Approve scopes
    A->>C: Access token (scoped)
    C->>S: Tool call + Bearer token
    S->>S: Validate token + check scopes
    S->>C: Tool result
    Note over C,S: Human-in-the-loop approval
for sensitive operations
          

The specification adds resource indicators and security guidance, but it cannot make every server safe. Do not pass tokens intended for one resource to another, and do not treat a tool description as permission to execute it.

Adoption evidence and its limits

A registry entry, a package download and a production deployment measure different things. For an integration decision, inspect the actual protocol revision, capability support, authentication configuration and operational owner.

Selected specification milestones

The Linux Foundation launch announcement dated December 9, 2025 identifies three founding project contributions: MCP, goose and AGENTS.md. It lists eight platinum members. These are launch facts, not a current membership count. Foundation governance does not by itself certify an implementation.

Where MCP helps

Our interpretation is that MCP addresses repeated integration work by making the application-service boundary reusable. That is a narrower claim than saying it has “won.” A team should still compare its maintenance cost with a direct API integration and check whether a client exposes the capabilities the workflow needs.

Function calling and MCP operate at different boundaries and can be used together. A model may request a tool call while an application fulfills that request through an MCP server. The comparison below describes design choices, not mutually exclusive architectures or universal properties of all implementations.

What comes next

Discovery should be treated as a separate design problem. A catalog can help locate a server, but the application must still validate the destination, version, capabilities and credentials before use. This article makes no claim that arbitrary server discovery or autonomous connection is safe or universally implemented.

The useful outcome is a reusable interface whose permissions, failures and returned evidence are visible to the application. Protocol support is one part of that system, not proof that the system is trustworthy.

Factual review: October 26, 2026. Original publication date retained. Primary sources are linked alongside the revised claims. Protocol details are pinned to the March and June 2025 specifications.