Agentic AI Engineering · Module 10 of 16

Model Context Protocol (MCP)

MCP is a standard way for an AI host to discover and call capabilities exposed by MCP servers. It can standardize connectivity to tools and data, but the host and server still need identity, authorization, policy, validation and safe tool design.

Engineering focus: Model Context Protocol 2026-07-28: clients, servers, tools and secure connectivity

In plain English

What problem are we solving?

Framework names come later. First understand what the application is doing and where its control boundaries belong.

Running case · Operations Investigator

Across the course, imagine an assistant that investigates operational problems using narrow tools. The design progressively adds plans, specialist agents, approvals, reliability controls and MCP while keeping model output separate from execution authority.

Learning objectives

By the end of this module, you should be able to:

Explain the host, client and server roles and the difference between tools, resources and prompts.
Describe the current 2026-07-28 stateless protocol at a beginner level, including optional discovery and per-request metadata.
Separate MCP connectivity from authorization, approvals and agent policy.

MCP standardizes a connection boundary

An MCP host can manage client connections to one or more MCP servers. Servers expose capabilities through protocol-defined primitives such as tools, resources and prompts. MCP reduces custom integration work; it does not decide whether a capability is safe for a particular user or task.

Tool: an invokable capability
Resource: data/content the server exposes
Prompt: reusable prompt/template capability
Host/client: the application side that discovers and invokes server capabilities

Current spec note: 2026-07-28 is stateless at the protocol layer

The 2026-07-28 revision removed the old initialize/initialized handshake and Mcp-Session-Id protocol session. Each request is self-describing; clients can use server/discover when they want server capabilities up front, but discovery is not required for every call.

Application state can still exist. A tool can return an explicit handle that later calls pass back as a normal argument.

HTTP routing is explicit

For the 2026-07-28 Streamable HTTP path, the protocol version and method are visible in standard MCP headers, including MCP-Protocol-Version and Mcp-Method; tool calls also expose the tool name through Mcp-Name. Gateways can route, meter and apply policy without parsing arbitrary prompt text.

Authorization is still a separate control

A tool description is metadata, not permission. Remote MCP deployments use an OAuth-oriented resource-server model, and the current revision strengthens issuer validation and moves client registration toward Client ID Metadata Documents. MCP trust guidance also emphasizes explicit user consent and control around tool use, so an internal risk-tier policy does not replace the host's consent responsibilities. Use maintained SDKs for the details rather than copying old OAuth snippets.

Long-running work uses an extension

In the 2026-07-28 ecosystem, Tasks is an extension rather than experimental core protocol. A supported tools/call can return a task handle; the client can follow it with tasks/get, tasks/update or tasks/cancel. There is no tasks/list in the current Tasks extension.

Worked examples

Conceptual MCP topology

AI Host
  ├─ MCP client → Files MCP server
  ├─ MCP client → Git MCP server
  └─ MCP client → Operations MCP server
                         ├─ tools
                         ├─ resources
                         └─ prompts

MCP standardizes the integration boundary.
Each server can expose a different trust and permission surface.

Modern request shape — simplified

MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_service_status

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_service_status",
    "arguments": {"service": "nginx"},
    "_meta": {"...client/version/capability metadata...": "..."}
  }
}

The modern protocol carries request identity/version information per request rather than relying on the old protocol session handshake.
This is a teaching simplification; use an official MCP SDK for production wire handling.

Try it · core lab · account-free

Validate a modern MCP request boundary

Goal: Inspect simplified 2026-07-28 discovery/tool-call envelopes and prove that a protected tool still requires application authorization.

Before you start

Python 3 only. This is a protocol-concepts simulator, not a replacement for an official MCP SDK.

STEP 1

Run the MCP concepts lab

python3 public/labs/agentic-ai/10_mcp.py

STEP 2

Inspect the modern request metadata

The simulator checks protocol version, Mcp-Method/Mcp-Name and per-request metadata without creating a protocol session.

STEP 3

Try a protected tool without authorization

The simulated server must reject the call even though the tool is discoverable.

Download this Python lab Download all current labs

Verify

server/discover and a read-only tools/call pass the modern-envelope checks.
A protected tool call fails without authorization and succeeds only with the simulated bearer identity.

Expected outcome

You can explain that discovery is not authorization.
You can identify old session/initialize tutorials as pre-2026 protocol-era material.

Break / fix · diagnose

If an old-style session ID appears in the modern path, revisit the 2026-07-28 stateless model.
If a protected tool executes without identity, check the authorization gate before dispatch.

Production view

MCP is an interoperability layer. Production safety still depends on server-side authorization, narrow tool contracts, risk-aware approval, observability and the host's policy around which servers and capabilities may be used.

Avoid these traps

Common mistakes

Assuming an MCP server is trusted merely because it speaks MCP.
Using old initialize/session tutorials as if they describe the 2026-07-28 protocol revision.
Treating tool annotations or descriptions as authorization enforcement.
Exposing a powerful MCP server to an agent without scoping identity, tools and data.

Knowledge check

Explain the control decision, not just the vocabulary.

Open every answer only after committing to your own answer. Opening all four answers records knowledge-check activity in My Learning.

1What major lifecycle change arrived in MCP 2026-07-28?

The protocol core became stateless: the old initialize/initialized handshake and Mcp-Session-Id protocol session were removed for the modern revision.

2Is server/discover required before every MCP tool call in the modern revision?

No — it is available for clients that want capabilities up front; modern requests are self-describing.

3If a tool appears in tools/list, is the caller automatically authorized to use it?

No — discovery and authorization are separate; protected capabilities still require identity and server-side policy.

4How is long-running tools/call work represented in the current MCP ecosystem?

Through the Tasks extension, which can return a task handle and supports tasks/get, tasks/update and tasks/cancel.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Core lab attemptedRecord this after meaningfully completing or attempting the module's core lab.Knowledge checks attemptedThis is marked automatically after you open every answer in the module; you can also record it manually.

Attempt the core lab and knowledge checks before marking the module complete.