MCP, the Model Context Protocol, is a standard way for an AI app to connect to outside tools and data. Picture a library service with three parts:

• The host is the app the person uses. It manages the interface, model and host-side permission rules.
• The client is the connector inside that host. It manages one connection to one server.
• The server is a separate program offering tools, readable resources or reusable prompts. Our server looks up fictional course resources.

The model may ask for a tool. Both the host and server must enforce their own access rules.

JSON-RPC 2.0 is a convention for request and reply messages. A request names a method, may include params, and has an id. The reply repeats that ID with a result or error. A notification has no ID and expects no reply.

This course pins MCP revision 2026-07-28. Every request carries protocol details in params._meta: protocol version, client name/version and client capabilities. Empty capabilities means no optional features. The official key prefix prevents name clashes. Client information is self-reported, so it does not prove user identity.

Revisions through 2025-11-25 used an initialize handshake instead. Do not mix their lifecycle with the pinned revision. First complete AI Tools and Approved Workflows. Use Node.js 22 or newer; Node 24 is the current long-term support release. Required examples use built-in modules, fictional data and no paid model.

Save the following as mcp-roles-messages.mjs and run node mcp-roles-messages.mjs.

const metadata = {
  'io.modelcontextprotocol/protocolVersion': '2026-07-28',
  'io.modelcontextprotocol/clientInfo': { name: 'cedar-course-client', version: '1.0.0' },
  'io.modelcontextprotocol/clientCapabilities': {}
};
const request = { jsonrpc: '2.0', id: 'read-1', method: 'tools/list',
  params: { _meta: metadata } };
const response = { jsonrpc: '2.0', id: request.id,
  result: { resultType: 'complete', tools: [] } };
console.log(request.method, response.id === request.id);
console.log(request.params._meta['io.modelcontextprotocol/protocolVersion']);

Expected output: tools/list true, then 2026-07-28. Nothing is sent over a network and no tool runs; the script only builds and compares the two messages.

1. Draw a host containing a model-facing interface and one MCP client connected to a directory server.
2. Label where the verified user/account context, tool allowlist, approval UI and server validation live.
3. Write example requests for server/discover, tools/list and tools/call with distinct IDs and per-request metadata.
4. Add a notification example and explain why the client should not wait for its response.

Replace the response ID with another request's ID. Simulate two pending requests in a map and show how the client misattributes the result. Restore matching IDs and reject unknown response IDs.

Question: Does clientInfo prove identity?

Answer: No. It is self-reported metadata.

Question: Does MCP itself grant course access?

Answer: No. The application must enforce permissions.

Question: Why pin a revision?

Answer: Lifecycle and transport behavior differ between versions, so interoperability claims need source history.

Deliver an architecture diagram and message fixtures with version notes. Keep protocol roles separate from model behavior so you can test the server without an AI provider.

Next, you will ask a server which revisions it supports and handle a mismatch.

MCP architecture, base protocol and versioning. Pinned revision 2026-07-28; reviewed 2026-10-07.