Protocols
AI applications need a structured way to discover context, call tools, and move results across boundaries. MCP is the main worked example here.
Common shape
Before shared protocols, every AI app needed custom integrations for every service: one way to talk to GitHub, another way to talk to a database, another way to read local files, and so on.
A protocol gives tool builders a common shape. If a host supports that protocol, it can connect to many compatible adapters. If an adapter speaks that protocol, many hosts can use it.
In practice
A protocol helps hosts and capabilities meet each other cleanly. It does not decide goals, approvals, or the whole agent loop.
ELI5: A travel plug that lets the same device fit a different wall socket.
What it actually is: A standardized interface that exposes tools, resources, or prompts so more than one host can discover and call them.
Try it: Build the shape in lab 03.
Real tools: MCP servers, OpenAPI-described services, LSP servers.
ELI5: Sometimes the appliance ships with ports built in, so you do not need an external adapter.
What it actually is: Many hosts now ship built-in file, shell, Git, or web tools that overlap with what a protocol adapter could expose.
Try it: Compare the protocol layer in lab 03 with the host layer in lab 09.
Real tools: Claude Code-style built-ins, Copilot CLI tool surfaces, Goose + MCP, Gemini CLI + MCP.
Connection shape
The application that coordinates the experience: a CLI assistant, IDE, desktop chat app, or internal tool.
Owns UX, approvals, conversation, and model access.
The host-side connection object. Users usually do not interact with it directly.
Maintains one dedicated connection to one server.
A program that exposes capabilities and context to the host in a standardized way.
Can run locally over stdio or remotely over HTTP.
MCP primitives
Plain English: Actions the model can ask to run.
Technical: Model-controlled executable functions with names, descriptions, input schemas, and structured results.
Example: create_issue, query_database, get_weather.
Plain English: Data the host can load as context.
Technical: URI-addressed content such as files, records, schemas, logs, or API responses.
Example: file:///project/README.md, database schema, Sentry event.
Plain English: Reusable instruction templates.
Technical: Server-provided prompt definitions that can take arguments and return structured messages.
Example: "review this code", "summarize this incident".
Transport
The host starts a local process and communicates over standard input and output. This is common for local filesystem tools, local scripts, and developer-machine integrations.
Good for local tools and simple installation.
The host talks to a remote server over HTTP, often with bearer tokens, API keys, OAuth, or other service authentication.
Good for hosted services and shared enterprise integrations.
Auth note: protocol auth and secret safety are different problems. See API key security.
Boundary check
| Question | Protocol answers? | What usually answers it |
|---|---|---|
| How does the host discover tools? | Yes | MCP tools/list, resources/list, prompts/list. |
| Which tool should the model use? | Partly | The model, host, agent runtime, system prompt, and tool descriptions. |
| Should the user approve the action? | No | The host app, policy layer, hooks, or enterprise controls. |
| How should a multi-step task be planned? | No | The agent runtime or orchestration framework. |
| Where does long-term memory live? | Maybe | A memory service could be exposed through a protocol, but memory policy is broader than the protocol. |
Walkthrough
The host starts the adapter. A desktop or CLI assistant launches a local filesystem MCP server over stdio.
The host discovers what exists. It asks for resources and tools, then learns that project files can be read.
The model asks for context. The host reads a file resource or calls a tool, then feeds the result back into the conversation.