All videosContext engineering2:14

MCP: protocol and trust

Connecting two servers does not authorise either to receive the other’s data.

Links containing ?t= open the video at a specific second.

Video summary

The ideas to retain

01

1. Start with ownership: host, client, and server are not synonyms

The MCP architecture defines three distinct roles.[^mcp-architecture]

02

Host

The host is the AI application: an IDE, desktop app, chat interface, internal agent, or another product that embeds the model experience.

03

Client

An MCP client lives inside the host and has a 1:1 relationship with one particular server.[^mcp-architecture]

Key moments

Jump directly to a section

  1. The host keeps the policy
  2. Data, templates and actions
  3. The version changes the contract
  4. A label does not enforce a limit
  5. A timeout does not prove the outcome
  6. Transport does not confer authority
Read the reviewed transcript

This video has no narration. This transcript reproduces its on-screen text; it does not invent a spoken track.

The host keeps the policy

The host application manages clients that communicate with MCP servers.

Each server exposes capabilities; the host decides what enters the model context.

Connecting two servers does not authorise either to receive the other’s data.

Data, templates and actions

A resource provides URI-identified data; a prompt provides a template.

A tool describes a callable operation and its accepted arguments.

Schema validity does not grant permission to execute. Policy applies to the specific operation.

The version changes the contract

In MCP 2026-07-28, each request carries protocol metadata; it no longer uses initialize.

Two requests may reach different instances. Business state must remain explicit.

server/discover can query capabilities. The client need not always call it first.

A label does not enforce a limit

The server labels a tool read-only. That annotation is a hint, not a guarantee.

The application limits capabilities and the protected service checks actual permissions.

An unauthorised write must fail even when the tool description sounds safe.

A timeout does not prove the outcome

A refund request reaches the service, but its response is lost.

A timeout proves neither failure nor completion. Repeating it can duplicate the effect.

An operation ID and read-back reconcile the state before a retry.

Transport does not confer authority

A resource contains text asking to send a secret to an external destination.

The text keeps its untrusted origin; it does not become host policy.

Egress controls and permissions prevent the effect. MCP connects systems; it does not decide which data is trusted.