MCP and orchestration

MCP Primitives and Lifecycle Reference

Use MCP hosts, clients, servers, capabilities, transports, tools, resources, and prompts without confusing protocol roles or trust boundaries.

Core conceptAnthropicOpenAIGoogle
CurrentNext review due 2026-08-24Content version 0.30.0
Format
Reference
Level
Beginner
Audience
Learner, Practitioner, Developer, Operator
Owner
Project42 Editorial
Review cadence
Every 30 days
Prerequisites
Basic familiarity with AI tools and client-server systems
01

Map the roles and layers

An MCP host is the AI application that coordinates one or more MCP clients. Each client maintains a connection to an MCP server. The data layer uses JSON-RPC messages for lifecycle, capabilities, primitives, and notifications; the transport layer carries those messages through local standard input/output or remote Streamable HTTP.

Servers can expose tools for executable operations, resources for contextual data, and prompts for reusable interaction templates. Clients can offer capabilities such as sampling, elicitation, and logging. Availability is negotiated during initialization, so never assume that a feature, method, or notification exists merely because another server supports it.

02

Record an MCP integration map

Separate protocol facts from product adapters. Record the negotiated protocol version, declared capabilities, identities, transport, authentication, primitive inventory, approval behavior, and failure policy. Tool descriptions and annotations from an untrusted server are claims, not enforcement.

MCP integration map
text
Use case: [BOUNDED OUTCOME]
Host: [PRODUCT, VERSION, OWNER]
Client connection: [NAME, VERSION]
Server: [IDENTITY, VERSION, OWNER, SOURCE]
Transport: [STDIO | STREAMABLE HTTP]
Authentication: [NONE | METHOD AND CREDENTIAL OWNER]
Negotiated protocol: [VERSION]
Client capabilities: [CAPABILITIES]
Server capabilities: [CAPABILITIES]
Tools: [NAME -> READ/WRITE, SIDE EFFECT, APPROVAL]
Resources: [URI CLASS -> DATA CLASSIFICATION]
Prompts: [NAME -> TRUST/REVIEW STATUS]
Notifications/tasks: [SUPPORTED BEHAVIOR]
Timeout and cancellation: [POLICY]
Failure behavior: [FAIL CLOSED | DEGRADED MODE]
Rollback: [DISCONNECT, DISABLE, OR RESTORE METHOD]
Evidence: [INITIALIZATION TRACE, INVENTORY, TEST]
03

Expected evidence and verification

The expected evidence is a current integration map tied to observed initialization and discovery results, not a generic feature list.

Connect in a safe environment, capture the negotiated version and capabilities, list each enabled primitive, run one read-only representative operation, exercise timeout and cancellation where supported, and confirm the documented failure behavior. Disable or disconnect the server and verify the host returns to its prior state.