← All notes

Summary

The Model Context Protocol is how an AI application connects to programs that offer tools, data, and prompt templates. It does not decide how that application calls a model or stores context. A separate abstract about multi-turn coding agents is useful next to that, because tool schemas and tool output are a large part of the token bill once an agent runs for many turns.

Who talks to whom

An MCP host is the AI application. The page names Claude Code, Claude Desktop, and Visual Studio Code. The host opens one client per server. That client keeps the connection and fetches context for the host.

A server is the program that serves context, local or remote. Standard input and output usually serves one client and has no network hop. Streamable HTTP usually serves many, using POST, optional server-sent events, and HTTP credentials. The docs recommend OAuth for tokens. The same JSON-RPC 2.0 messages ride on either transport.

MCP does not say how the application calls a model or stores the context it receives. SDKs hide framing. The useful part is the data layer.

What to call

The protocol is stateless. Every request carries the protocol version and the relevant capabilities, and clients should name themselves unless told not to. Servers must implement discovery. Calling it first is optional. A rejected version comes back with the versions the server supports.

Servers expose three primitives. Tools are functions the app can run, such as file, API, or database work. Resources are data, such as a file or a record. Prompts are reusable templates. Clients list them, then read or call. Names must match the list, and tool arguments must match the input schema. Results come back as content objects. The host routes the model's tool call to the client that owns that tool and puts the result back in the conversation.

Clients can offer elicitation so a server can ask the user for input or confirmation. Sampling and client-side logging are deprecated as of the protocol version on the page. New servers should call a model API themselves, and should log to standard error on the local transport or use OpenTelemetry.

Change notices are opt-in, expect no reply, and are best effort across reconnects, so also poll. A tasks extension can hand back a handle for a long request.

Tokens on a long tool-using run

The cost abstract is not about MCP. It measures a compression gateway between coding agents and frontier models, and splits the bill into tool-schema filtering, compression of file reads and tool output, and history summarization. Those levers did not save at the same rate.

Schema filtering removes a fixed block every turn. It grows in a straight line with turn count, and it was the only lever the abstract calls unambiguously and reproducibly positive.

Compressing read content saves only a small share of the cache-priced prefix on one turn. The compressed text stays in history and is sent again later, so the cumulative saving grows much faster until the window caps it. If the agent can pull original bytes back, each recall resends exactly the segment just removed. That extra cost is bounded, but heavy recall spends the saving one segment at a time.

A strong single-shot compression score is a different result. The abstract says it is orthogonal to multi-turn agent cost and must not be cited as proof of savings.

Attach fewer or smaller tool schemas first. If you compress tool output, assume it will be replayed, and assume recalls give some of the saving back.

Claims

• id: C1 claim: A host creates one client per server, and each client keeps its own connection. source: S1 evidence: "The MCP host accomplishes this by creating one MCP client for each MCP server."
• id: C2 claim: MCP only specifies context exchange; it does not say how the application uses a model or stores context. source: S1 evidence: "MCP focuses solely on the protocol for context exchange"
• id: C3 claim: Local standard-input servers usually serve one client, while remote streamable-HTTP servers usually serve many. source: S1 evidence: "Local MCP servers that use the STDIO transport typically serve a single MCP client, whereas remote MCP servers that use the Streamable HTTP transport will typically serve many MCP clients."
• id: C4 claim: Tools, resources, and prompts are the three core primitives a server can expose. source: S1 evidence: "MCP defines three core primitives that servers can expose"
• id: C5 claim: Sampling and client logging are deprecated in the protocol version named on the architecture page. source: S1 evidence: "The following client primitives are deprecated as of protocol version 2026-07-28"
• id: C6 claim: Tool-schema filtering removes a fixed block every turn and was the only clearly reproducible saving in their isolated tests. source: S2 evidence: "Tool-schema filtering removes a fixed block every turn"
• id: C7 claim: A single-shot compression score does not show that compression saves money in a multi-turn agent. source: S2 evidence: "is orthogonal to multi-turn agent cost and must not be cited as a cost-saving argument."
• id: C8 claim: Recalling original bytes resends only the segment just compressed, so that extra cost stays bounded. source: S2 evidence: "each recall re-sends exactly the one segment just compressed away, so its cost is fixed and bounded"

@misc{iil_note_b2x8dp5b,
  author = {{iinventedlight}},
  title = {{MCP for agents}},
  howpublished = {iinventedlight Library},
  year = {2026},
  date = {2026-11-03},
  url = {https://iinventedlight.com/library/notes/ao-mcp/},
  note = {Permanent ID iil:note:b2x8dp5b. License: CC-BY-4.0.},
}

Markdown

Spotted a mistake? Use the MCP feedback tool or email hello@iinventedlight.com.

For language models and agents: start at /llms.txt. This page in Markdown: /library/notes/ao-mcp.md.