← All chapters
MCP & Integration
Model Context Protocol and patterns for tool-connected, integrated AI apps.
21 terms
Capability NegotiationCapability negotiation is the handshake that occurs at the start of an MCP session where the client and server exchange their supported protocol versions and optional feature sets. The server declares which capabilities it supports — such as tools, resources, prompts, or sampling — and the client records this information to determine which protocol methods it may invoke. Negotiation ensures backward compatibility across protocol versions and prevents clients from calling methods a server has not implemented.Host ApplicationIn the MCP architecture, the host application is the end-user-facing program that integrates the language model and embeds the MCP client. Examples include Claude Desktop, VS Code with Copilot extensions, or a custom chat interface. The host manages the user interface, controls which MCP servers are connected, and decides how to present tool results to users. It is responsible for enforcing security policies — such as user consent dialogs — before passing tool results back to the model.Integration SurfaceThe integration surface of an MCP server is the total set of tools, resources, and prompts it exposes — the complete API boundary that clients can interact with. Keeping the integration surface minimal and well-documented reduces the attack surface for prompt injection and tool misuse, and makes it easier for language models to select the correct tool without confusion. A focused integration surface also simplifies capability negotiation and version management as the server evolves.MCP ClientAn MCP client is the component embedded in a host application — such as Claude Desktop, an IDE, or a custom agent runtime — that establishes and manages connections to one or more MCP servers. The client is responsible for the handshake and capability negotiation, discovering available tools and resources, routing the model's tool-call requests to the correct server, and returning observations back into the model's context.MCP over HTTPMCP over HTTP is the remote transport variant where JSON-RPC messages are sent as HTTP POST requests and server-initiated messages are delivered via server-sent events on a persistent GET connection. This transport enables MCP servers to run as cloud services accessible from any network location, in contrast to the local-only stdio transport. HTTP transport is appropriate for multi-user deployments, hosted integrations, and cases where the server manages shared state across many client sessions simultaneously.MCP PromptAn MCP prompt is a reusable, parameterized message template exposed by an MCP server that a host application can inject into a conversation to guide the model's behavior for a specific task. Unlike a hardcoded system prompt, MCP prompts are discovered dynamically and can accept arguments that are substituted at render time. They allow server authors to encode best-practice instructions alongside their tools so that any compliant host automatically receives well-crafted guidance.MCP RegistryAn MCP registry is a directory or marketplace where developers publish their MCP servers so that host applications and users can discover, install, and configure them. Registries typically store server metadata — description, author, version, capability flags, and installation instructions — alongside trust signals such as verified authorship or audit status. A centralized registry lowers the discovery barrier for end users and enables host applications to offer one-click server installation.MCP ResourceAn MCP resource is a piece of content exposed by an MCP server that the model can read but that does not have side effects — such as a file, a database row, a web page, or a configuration document. Resources are identified by URIs and can be static or dynamic. Unlike tools, resources do not execute arbitrary logic; they provide a stable, addressable view of data that the model can incorporate into its context for grounding or reference.MCP ServerAn MCP server is a process that exposes capabilities — tools, resources, and prompt templates — to any compliant MCP client. The server implements the protocol's JSON-RPC methods, advertises its capabilities in a manifest, and handles tool invocations or resource reads on behalf of the connected host. Servers can be local processes, containerized services, or remote HTTP endpoints; the protocol is transport-agnostic so the same server code can run in multiple deployment modes.MCP SessionAn MCP session is the stateful connection between an MCP client and an MCP server, established through the initialize/initialized handshake and lasting until either party closes the connection. Sessions maintain a shared understanding of negotiated capabilities, active subscriptions, and protocol state. A single host application may maintain multiple simultaneous sessions with different servers, each independently managing its own capabilities and lifecycle.MCP ToolAn MCP tool is a callable function exposed by an MCP server that a language model can invoke to perform actions with side effects — such as running a query, sending an email, or writing a file. Each tool is described by a name, a human-readable description, and a JSON Schema that defines its input parameters. The model selects tools by name based on the descriptions surfaced during tool discovery, and the server executes the function and returns a structured result.Model Context ProtocolThe Model Context Protocol is an open standard that defines how AI models connect to external tools, data sources, and services through a common JSON-RPC interface. Rather than writing custom integrations for every combination of model and tool, developers implement a single MCP server that any compliant host can consume. Anthropic published the specification and first-party SDKs in late 2024; the protocol quickly gained adoption as a de-facto standard for agentic integrations.Resource SubscriptionResource subscription is an optional MCP capability that allows a client to register interest in a specific resource URI and receive server-initiated notifications when that resource changes. When a subscribed resource is updated, the server sends a notifications/resources/updated message, prompting the client to re-fetch the resource and update its context. Subscriptions enable live data scenarios — such as a dashboard that stays current with a frequently changing data source — without polling.RootsRoots are filesystem or URI boundaries that the host application declares to an MCP server at session initialization, indicating which locations the server is allowed to access. For example, a code editor might declare the open workspace directory as a root, telling the file-system MCP server to restrict all reads and writes within that path. Roots are a key security primitive: they give users and hosts fine-grained control over which data surfaces are exposed to each server.Sampling (MCP)MCP sampling allows an MCP server to request a model completion from the host application rather than calling a model API directly. The server sends a sampling request containing a messages array and optional model preferences, and the host — which already has the model connection — executes the completion and returns the result. This design keeps credentials and model access centralized in the host while allowing servers to leverage LLM capabilities for tasks like classification, summarization, or generation within a tool implementation.Security ScopesSecurity scopes are the explicit permission boundaries that govern what an MCP server is allowed to access or modify. Scopes may restrict file-system access to declared roots, network access to approved hosts, or API access to specific resource types. Host applications present scopes to users for approval at connection time, and well-designed clients refuse to forward tool results or resource reads that exceed the approved scope. Granular scopes limit blast radius if a server is compromised or manipulated via prompt injection.Server ManifestThe server manifest is the structured document an MCP server returns in response to an initialize request. It declares the server's name, version, protocol version compatibility, and the full set of capabilities it supports. The manifest is the first thing the client reads after connecting, and its contents determine which subsequent protocol methods the client will attempt to use. A well-authored manifest includes clear capability flags so that clients can adapt gracefully to partial implementations.Stdio TransportThe stdio transport runs the MCP server as a child process of the host application and exchanges newline-delimited JSON-RPC messages over the process's standard input and standard output streams. It is the simplest deployment model — no network configuration is required — and is ideal for locally installed tools such as CLI utilities, language runtimes, or desktop applications. Because the server process is spawned and terminated by the host, lifecycle management is straightforward.Structured Tool ResultA structured tool result is the typed response an MCP server returns after executing a tool call. Results may contain text, images, embedded resources, or error descriptors, each tagged with a content type. Returning machine-readable structure — rather than plain text — allows host applications to render rich UI (such as rendered code blocks or inline images) and allows downstream models to parse results reliably without free-text extraction heuristics.Tool DiscoveryTool discovery is the process by which an MCP client retrieves the list of tools available on a connected server by calling the tools/list protocol method. The server responds with each tool's name, description, and input schema. Host applications typically surface this list to the language model in the system prompt or as a special context block, enabling the model to choose the right tool without the developer manually specifying every available action.TransportIn MCP, a transport is the mechanism used to carry JSON-RPC messages between the client and server. The protocol currently defines two standard transports: stdio, where messages are exchanged over standard input and output of a child process, and HTTP with server-sent events for remote servers. The transport layer is intentionally decoupled from the protocol semantics, allowing the same server to be deployed locally or as a cloud service without changing the application logic.