A tool protocol is a boundary

The mechanism

A tool protocol supplies shared message and capability conventions at an application boundary. It does not decide which business action is correct or replace the host’s security policy. In MCP, the host contains the application context, a client communicates with a server, and server tools expose typed operations. Tool discovery describes what can be requested; invocation and the returned result remain separate messages. The protocol edition matters because lifecycle and extension rules can change. This lesson refers to the 2026-07-28 specification, whose core uses self-contained stateless requests and distinguishes optional extensions. The atlas incident tools illustrate schemas and permissions locally, but they are not an MCP wire implementation. The atlas’s separate host-provided navigation hook also does not prove conformance to this protocol edition.

A host decides which servers and capabilities are available to its application and user.
A client reads the server’s tool descriptions and checks the schema version it will use.
The server validates an invocation and returns a structured result or error; tool annotations do not grant trust.
The host interprets that observation under its task and authority policy, keeping optional extensions separate from the core contract.

Science and assumptions

A tool protocol is a boundary · explicit relationship

Host policy selects and constrains capabilities; the client exchanges versioned protocol messages; the server executes an allowed tool contract. Discovery is separate from invocation and correctness.

A fictional server advertises $reserve_{\mathrm{part}}$ with integer quantity and an idempotencyKey. Discovering the schema causes no reservation. An invocation with quantity "2" fails validation; quantity 2 may pass validation but still fail authority. A successful result naming reservation-1 is then checked against the task and source evidence. A protocol viewer should retain the tool contract and edition alongside these messages. Replaying this conceptual sequence does not establish that any real server supports a particular extension.

Assumptions The reference edition is MCP 2026-07-28. This is a worked protocol explanation, not an executing MCP client/server or conformance test.

Engineering example

Distinctions and tradeoffs

Interoperable message formats do not guarantee a trustworthy or correct action.

Standard messages can reduce adapter work, but version and extension compatibility remain explicit engineering obligations.

Tool-connected AI benefits from inspectable interfaces while retaining application-level control over effects.

Specifications and interfaces

Mechanism boundary: What does a protocol standardize, and what remains application policy?
The reference edition is MCP 2026-07-28. This is a worked protocol explanation, not an executing MCP client/server or conformance test.
Evidence type: Authored worked example
Worked explanation with a bounded numeric or state example. This lesson does not claim an executing implementation of an external model or platform.

Interfaces

Declared input and state Input: A host decides which servers and capabilities are available to its application and user.
Checked outcome Output: Identify host, client and server responsibilities without treating protocol transport as permission or task correctness.

Check your understanding

What does successful tool discovery establish?

That every discovered action is authorized
That the client has descriptions of available tool contracts
That the user’s task is complete

Answer and reasoning

That the client has descriptions of available tool contracts

Discovery supplies contracts; validation, authority, invocation and task evaluation still follow.

Evidence and scope

This is a worked explanation, not an executing external platform, model or robot. The quantities and fixtures are authored. Source scope is recorded in the automation learning review manifest; no source benchmark or private system behavior is claimed. The reference edition is MCP 2026-07-28. This is a worked protocol explanation, not an executing MCP client/server or conformance test.

The worked example explains this mechanism. General numerical labs are a reference; they do not execute this lesson’s full mechanism.