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.
- 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
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.
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.
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]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.