agent-readings

Tool Use and Interoperability

Model Context Protocol

MCP standardizes the protocol surface between AI applications and external context, tools, prompts, and client-mediated capabilities.

7Claims
7Evidence

Why It Matters

Agent infrastructure needs an interface contract. MCP gives hosts, clients, and servers a shared JSON-RPC vocabulary for discovery, invocation, context access, user prompts, and permission-sensitive client features.

Problem

  • LLM applications often used bespoke tool schemas, plugin manifests, local subprocess wrappers, or host-specific integration APIs.
  • A tool or data connector written for one host did not reliably compose with another host.
  • Tool calling, context injection, user prompts, and local filesystem scoping were mixed into application-specific conventions.
  • Security-sensitive questions such as user consent, tool invocation, data sharing, and sampling approval were left to each host to solve separately.

Key gap: The protocol asks how AI applications can discover and use external context and capabilities through a common client-server contract without prescribing the application shell or agent algorithm.

Method

Split an AI integration into a host, one client connection per server, and server/client capabilities negotiated at initialization; use JSON-RPC methods for listing, retrieving, invoking, and notifying changes.

  • A host application starts or connects to an MCP server through stdio, Streamable HTTP, or another compliant transport.
  • The host instantiates an MCP client for that server and negotiates capabilities during initialization.
  • The client discovers server-provided resources, prompts, and tools with list methods and pagination where supported.
  • The host chooses how to display or insert resources and prompts into the model context.
  • When the model chooses a tool, the host/client can present the invocation for user review, then send a tools/call request.
  • If supported, the server can ask the client for roots, model sampling, or structured user input, while the host retains permission and UI control.

Claims

C1 · spec-supported

MCP defines a host/client/server architecture using JSON-RPC 2.0, stateful connections, and capability negotiation for AI application integrations.

Scope: 2025-06-18 specification overview and architecture docs.

  • E-overview: The spec says MCP uses JSON-RPC 2.0, stateful connections, and server/client capability negotiation between hosts, clients, and servers. The architecture docs describe an MCP host creating one MCP client for each server connection.

C2 · spec-supported

The server-side interface is organized around resources, prompts, and tools, with different intended controllers: application, user, and model.

Scope: Server feature pages and server concepts docs.

  • E-server-primitives: Resources expose URI-addressed context and optional templates; prompts expose parameterized messages for explicit user invocation; tools expose named functions with input schemas and result content or structured output.

C3 · spec-supported

The client-side interface adds roots, sampling, and elicitation so servers can request filesystem scope, model generations, and structured user input through the host.

Scope: 2025-06-18 client feature pages.

  • E-client-primitives: Roots expose filesystem scopes; sampling lets servers request completions through clients; elicitation lets servers request structured user input with JSON schemas. The top-level spec lists all three as client features.

C4 · spec-supported

MCP currently standardizes stdio and Streamable HTTP transports for JSON-RPC messages, while allowing custom transports that preserve lifecycle requirements.

Scope: Transport specification.

  • E-transports: The transport spec defines UTF-8 JSON-RPC over stdio and Streamable HTTP, requires the Streamable HTTP endpoint to support POST and GET, adds session and protocol-version header rules, and allows custom bidirectional transports that preserve message format and lifecycle.

C5 · spec-supported

MCP includes trust-and-safety guidance for consent, data privacy, tool safety, and sampling control, but the protocol does not enforce those guarantees itself.

Scope: Specification security section and feature pages.

  • E-security-model: The spec identifies user consent, data privacy, tool safety, and sampling controls as key principles, warns that tools are arbitrary code execution, requires consent before exposing data or invoking tools, and says the protocol itself cannot enforce these principles.

C6 · spec-supported

Authorization is optional and, when used over HTTP transports, is specified as a subset of OAuth-based flows with protected-resource metadata and token handling.

Scope: Authorization specification.

  • E-authorization: Authorization is optional. HTTP-based transports should follow the authorization spec, stdio should retrieve credentials from the environment, and the HTTP flow is based on OAuth 2.1, authorization-server metadata, dynamic client registration, and protected-resource metadata.

C7 · docs-supported

Roots are a coordination mechanism for intended filesystem scope, not a hard security boundary against malicious server code.

Scope: Client concepts and roots documentation.

  • E-roots-limitation: The client docs state that roots coordinate server scope but are not a security boundary; they help trusted or vetted servers avoid accidental out-of-scope access but do not stop malicious behavior.

Agent Infrastructure Takeaways

  • MCP is the agent-tool driver model: the goal is to make connectors reusable across hosts instead of embedding each tool into one application.
  • Server primitives should be stored separately in review data: resources are context, prompts are reusable workflows, and tools are side-effecting functions.
  • Client primitives matter because they move sensitive actions back through the host: roots, sampling, and elicitation all require host/user policy decisions.
  • The protocol boundary is not the security boundary. Serious agent runtimes still need sandboxing, capability grants, audit logs, and consent UX.
  • Tool metadata is untrusted unless the server is trusted; hosts should not let model-visible descriptions become policy.
  • Streamable HTTP turns MCP into remote infrastructure, so DNS rebinding, authentication, session IDs, and protocol-version negotiation belong in deployment checklists.

Caveats

  • This is a specification and documentation corpus, not an empirical paper with benchmark results.
  • MCP changes over time; this review is anchored to the 2025-06-18 protocol revision while the README entry is dated by the 2024 launch.
  • The spec standardizes protocol shape, not context-ranking algorithms, model routing, tool planning, or workflow execution semantics.
  • Security outcomes depend on host and client implementation. The spec explicitly notes that MCP itself cannot enforce the security principles.
  • Roots are advisory coordination, not a containment boundary.
  • Remote MCP servers introduce operational concerns that local stdio integrations can avoid, including authentication, session handling, and DNS-rebinding risk.