{
  "schemaVersion": 1,
  "id": "atlas-lesson-mcp-host-client-server",
  "title": "A tool protocol is a boundary",
  "category": "learning",
  "format": "Atlas lesson",
  "description": "Version-pinned MCP host/client/server roles, schema discovery, invocation and errors.",
  "canonicalUrl": "https://semiaifoundry.com/learn/atlas/mcp-host-client-server/",
  "publishedDate": null,
  "revisionDate": "2026-10-07",
  "author": null,
  "topic": "Authority, context and execution boundaries",
  "series": null,
  "license": null,
  "rightsUrl": "https://semiaifoundry.com/ai-atlas/licenses.html",
  "version": "1.3.0",
  "status": "Published educational lesson",
  "evidenceScope": "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.",
  "contentCoverage": "published-lesson",
  "artifactUrl": "https://semiaifoundry.com/ai-atlas/lesson-data/mcp-host-client-server-0e820e6ae04e5210.json",
  "interactiveUrl": "https://semiaifoundry.com/ai-atlas/#mcp-host-client-server",
  "related": [],
  "supersedes": [],
  "supersededBy": [],
  "contentHash": "156e8be193fb111398fb645cde5c2764d3e86ede96b26154a95772290685e669",
  "contentLength": 6353,
  "jsonUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-mcp-host-client-server.json",
  "markdownUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-mcp-host-client-server.md",
  "sections": [
    {
      "id": "section-1",
      "title": "A tool protocol is a boundary",
      "start": 60,
      "end": 475
    },
    {
      "id": "section-2",
      "title": "The mechanism",
      "start": 475,
      "end": 1806
    },
    {
      "id": "section-3",
      "title": "Science and assumptions",
      "start": 1806,
      "end": 1834
    },
    {
      "id": "section-4",
      "title": "A tool protocol is a boundary · explicit relationship",
      "start": 1834,
      "end": 2789
    },
    {
      "id": "section-5",
      "title": "Engineering example",
      "start": 2789,
      "end": 3359
    },
    {
      "id": "section-6",
      "title": "Distinctions and tradeoffs",
      "start": 3359,
      "end": 3708
    },
    {
      "id": "section-7",
      "title": "Specifications and interfaces",
      "start": 3708,
      "end": 4161
    },
    {
      "id": "section-8",
      "title": "Interfaces",
      "start": 4161,
      "end": 4445
    },
    {
      "id": "section-9",
      "title": "Check your understanding",
      "start": 4445,
      "end": 4474
    },
    {
      "id": "section-10",
      "title": "What does successful tool discovery establish?",
      "start": 4474,
      "end": 4859
    },
    {
      "id": "section-11",
      "title": "Evidence and scope",
      "start": 4859,
      "end": 5406
    },
    {
      "id": "section-12",
      "title": "Sources",
      "start": 5406,
      "end": 5910
    },
    {
      "id": "section-13",
      "title": "Continue exploring",
      "start": 5910,
      "end": 5933
    },
    {
      "id": "section-14",
      "title": "Foundations",
      "start": 5933,
      "end": 6163
    },
    {
      "id": "section-15",
      "title": "Related lessons",
      "start": 6163,
      "end": 6353
    }
  ],
  "citations": [
    {
      "title": "Explore in Atlas",
      "url": "https://semiaifoundry.com/ai-atlas/#mcp-host-client-server"
    },
    {
      "title": "Model Context Protocol specification",
      "url": "https://modelcontextprotocol.io/specification/2026-07-28"
    },
    {
      "title": "MCP tools",
      "url": "https://modelcontextprotocol.io/specification/2026-07-28/server/tools"
    },
    {
      "title": "MCP authorization",
      "url": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization"
    },
    {
      "title": "Published lesson data",
      "url": "https://semiaifoundry.com/ai-atlas/lesson-data/mcp-host-client-server-0e820e6ae04e5210.json"
    },
    {
      "title": "Atlas releases and licensing",
      "url": "https://semiaifoundry.com/ai-atlas/licenses.html"
    },
    {
      "title": "Tool schemas and semantic validation",
      "url": "https://semiaifoundry.com/learn/atlas/tool-contracts-schemas/"
    },
    {
      "title": "User authority and service identity",
      "url": "https://semiaifoundry.com/learn/atlas/tool-authority-identity/"
    },
    {
      "title": "Tools, memory & agent loop",
      "url": "https://semiaifoundry.com/learn/atlas/tool-loop/"
    },
    {
      "title": "Evaluation & the AGI frontier",
      "url": "https://semiaifoundry.com/learn/atlas/evaluation/"
    }
  ],
  "recordHash": "d9c478a755add7fd18b00a9d90bbd04638e6558670a734b2d3f706f97d888003",
  "contentFormat": "text/markdown",
  "content": "Authority, context and execution boundaries · Atlas v1.3.0\n\n# A tool protocol is a boundary\n\nVersion-pinned MCP host/client/server roles, schema discovery, invocation and errors.\n\n[Explore in Atlas](https://semiaifoundry.com/ai-atlas/#mcp-host-client-server)Logical state, task evidence and declared units; no physical assembly scale\n\nLearning objectiveIdentify host, client and server responsibilities without treating protocol transport as permission or task correctness.\n\n## The mechanism\n\nA 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.\n\n1.  A host decides which servers and capabilities are available to its application and user.\n2.  A client reads the server’s tool descriptions and checks the schema version it will use.\n3.  The server validates an invocation and returns a structured result or error; tool annotations do not grant trust.\n4.  The host interprets that observation under its task and authority policy, keeping optional extensions separate from the core contract.\n\n## Science and assumptions\n\n### A tool protocol is a boundary · explicit relationship\n\nHost 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.\n\nA 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.\n\nAssumptions The reference edition is MCP 2026-07-28. This is a worked protocol explanation, not an executing MCP client/server or conformance test.\n\n## Engineering example\n\nA 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.\n\n## Distinctions and tradeoffs\n\nInteroperable message formats do not guarantee a trustworthy or correct action.\n\nStandard messages can reduce adapter work, but version and extension compatibility remain explicit engineering obligations.\n\nTool-connected AI benefits from inspectable interfaces while retaining application-level control over effects.\n\n## Specifications and interfaces\n\nMechanism boundary\n\nWhat does a protocol standardize, and what remains application policy?\n\nThe reference edition is MCP 2026-07-28. This is a worked protocol explanation, not an executing MCP client/server or conformance test.\n\nEvidence type\n\nAuthored worked example\n\nWorked explanation with a bounded numeric or state example. This lesson does not claim an executing implementation of an external model or platform.\n\n### Interfaces\n\nDeclared input and state Input\n\nA host decides which servers and capabilities are available to its application and user.\n\nChecked outcome Output\n\nIdentify host, client and server responsibilities without treating protocol transport as permission or task correctness.\n\n## Check your understanding\n\n### What does successful tool discovery establish?\n\n1.  That every discovered action is authorized\n2.  That the client has descriptions of available tool contracts\n3.  That the user’s task is complete\n\nAnswer and reasoning\n\nThat the client has descriptions of available tool contracts\n\nDiscovery supplies contracts; validation, authority, invocation and task evaluation still follow.\n\n## Evidence and scope\n\nThis 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.\n\nThe worked example explains this mechanism. General numerical labs are a reference; they do not execute this lesson’s full mechanism.\n\n## Sources\n\n-   [Model Context Protocol specification](https://modelcontextprotocol.io/specification/2026-07-28)\n-   [MCP tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)\n-   [MCP authorization](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)\n\n[Published lesson data](https://semiaifoundry.com/ai-atlas/lesson-data/mcp-host-client-server-0e820e6ae04e5210.json) · [Atlas releases and licensing](https://semiaifoundry.com/ai-atlas/licenses.html)\n\n## Continue exploring\n\n### Foundations\n\n-   [Tool schemas and semantic validation](https://semiaifoundry.com/learn/atlas/tool-contracts-schemas/)\n-   [User authority and service identity](https://semiaifoundry.com/learn/atlas/tool-authority-identity/)\n\n### Related lessons\n\n-   [Tools, memory & agent loop](https://semiaifoundry.com/learn/atlas/tool-loop/)\n-   [Evaluation & the AGI frontier](https://semiaifoundry.com/learn/atlas/evaluation/)"
}