Project 42Start learning
Module 5 of 12 · 48 min

Understand MCP Architecture and Contracts

Model the host, client, server, lifecycle, capabilities, primitives, and tool contracts that let AI applications connect to external context and actions.

Core concept

By the end

You will be able to

  • Explain MCP host, client, and server responsibilities without collapsing their trust boundaries.
  • Trace initialization, protocol-version agreement, capability negotiation, operation, and shutdown.
  • Distinguish prompts, resources, and tools by who controls them and what risk they introduce.
  • Design a narrow MCP tool contract with typed inputs, outputs, errors, and human-control points.
01

Start with three roles and one connection per server

An MCP host is the AI application that coordinates policy, consent, model access, and multiple connections. It creates an MCP client for each server. Each client maintains an isolated one-to-one session with its server and routes protocol messages.

An MCP server exposes focused capabilities. Local and remote servers can have very different deployment and credential risks, but neither becomes trusted merely because it speaks MCP. Keep the host responsible for aggregation and user decisions so one server cannot silently observe another server's data.

Responsibility map
text
HOST: user intent, consent, policy, model, aggregation
  CLIENT A: session + capability state <-> SERVER A: files
  CLIENT B: session + capability state <-> SERVER B: tickets
Rule: data crosses connections only through an explicit host decision.
02

Negotiate before operating

The MCP lifecycle begins with initialization. Client and server agree on a protocol revision and advertise capabilities before normal operation. Each side must use only features that were successfully negotiated.

Treat capability state as runtime evidence. A configured tool name does not prove that a server currently exposes it, supports notifications, or implements the protocol revision your client expects. Fail closed or degrade deliberately when negotiation is incomplete.

03

Prompts, resources, and tools have different control models

MCP describes prompts as user-controlled templates, resources as application-controlled context, and tools as model-controlled functions. This control hierarchy is a design aid, not an authorization system.

Resources and tool results remain untrusted input. Tool discovery tells a model what may be requested; the host still decides what is exposed, what requires confirmation, and what a trusted executor will authorize.

04

Make tool contracts narrow and inspectable

A tool definition needs a stable name, a decision-oriented description, and a JSON input schema. Use precise types, required fields, enums, bounds, and descriptions that distinguish similar tools. Where supported, publish an output schema and return structured content that can be validated.

Document side effects, idempotency, error classes, approval policy, and the postcondition separately from the schema. An input schema constrains syntax; it cannot prove identity, ownership, authorization, or a successful real-world effect.

Narrow MCP tool
json
{
  "name": "create_training_draft",
  "description": "Create one unpublished draft in the named workspace.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "workspaceId": {"type": "string", "pattern": "^ws_[a-z0-9]{8}$"},
      "title": {"type": "string", "minLength": 3, "maxLength": 120}
    },
    "required": ["workspaceId", "title"],
    "additionalProperties": false
  }
}
05

Separate the portable contract from provider adapters

Anthropic and OpenAI expose ways to connect remote MCP servers, while Google ADK documents MCP tools within its own agent framework. Their request shapes, supported transports, approval surfaces, and release maturity can differ.

Keep learning objectives and application policy provider-neutral: required capability, approved server identity, allowed tool set, data policy, approval rule, and expected result. Put provider-specific headers, SDK objects, connector identifiers, and limitations in replaceable adapters verified against current documentation.

Practice activity

Design and negotiate an MCP integration

  1. Draw the host, one client per server, server capabilities, credentials, data flows, and user-control points for a two-server learning assistant.
  2. Write an initialization record containing protocol version, advertised capabilities, accepted capabilities, and the behavior when a required capability is absent.
  3. Define one read tool and one write tool with narrow input schemas, stable result and error shapes, side-effect documentation, and postcondition checks.
  4. Map the portable contract to one current Anthropic, OpenAI, or Google adapter and list every provider-specific assumption.

What to produce

  • An architecture and lifecycle record that preserves connection and trust boundaries.
  • Two tool contracts plus a provider-adapter table showing negotiation, approvals, errors, and unsupported behavior.

Reflect before continuing

Which part of the design initially looked like protocol plumbing but actually belonged to application policy?

Evidence

Sources and verification

Knowledge check

Make it stick.

Pass at 80%

Choose the strongest answer for each question. Your attempts become part of your device-local transcript.

01Which component should own user consent and coordinate policy across MCP connections?
02A server is configured but did not advertise the tools capability during initialization. What should the client do?
03What does a valid MCP input schema prove?
04Why should a host normally create a separate client for each server?
05What is the most portable way to support several providers?