MCP Foundations: overview

Larkspur wants its handbook search reused by several hosts without copying tool definitions into each one. You will move the tools behind an MCP server, inspect discovery and call messages and compare local subprocesses with remote sessions. The tutorials cover server-client roles, tools, resources, prompts, reference servers and remote transport.

The notebooks wrap an arXiv research server. These pages also put the Larkspur Cloud handbook from T5.1 to T5.3 behind MCP, which is the module's lab brief: a FastMCP server called larkspur-handbook with the T5.1 retriever as its one tool, search_handbook, the handbook chunks as resources, and an answer_with_citations prompt. The golden question is the T5.1 one, How long does a refund take? Every message, schema and status code quoted here was recorded from real runs with MCP Python SDK 1.30.0, the version in the course's protocols dependency group.

• An MCP server owns the tools; the chatbot keeps the loop. The client launches a stdio server as a subprocess, opens one session per server, sends initialize (protocol version 2025-11-25 in SDK 1.30.0), then tools/list and tools/call as the model asks.
• FastMCP builds each tool definition from the Python function: the function name, the whole docstring as the description, and a JSON schema from the type hints. The Args: lines stay inside the description; no parameter gets a schema description of its own.
• Tools are for the model to call. Resources and prompts are for the application and the user: the lesson 7 chatbot reads a resource when the user types @topic and fetches a prompt on /prompt.
• Every connected server's tools go to the model on every call. The notebook's three servers send 17 definitions, about 2,527 tokens, and the filesystem server is 80% of that. Two filesystem servers send 14 names twice, and the chatbot routes all 14 to the second one.
• Remote servers run on their own and the client connects by URL. Streamable HTTP uses one endpoint, /mcp, and an mcp-session-id header; the older SSE transport uses a stream at /sse plus POSTs to /messages/.

The client and the server agree on a protocol version and capabilities once, then the client lists what the server offers. The model sees only the tool definitions; it never talks to the server. When it asks for a tool, the chatbot hands the call to the session that owns that tool, and the result goes back to the model as a tool result. Swap the server for another and the chatbot code does not change.

Server config lab: open the file in a browser. Start with Notebook config and read the ledger: 17 tool definitions and 10,107 characters go out with every request, and filesystem sends 14 of them. Switch on larkspur to add the handbook retriever for 417 characters. Then pick Two filesystem servers: the first filesystem server still sends 14 definitions but gets 0 calls, and the file the model asks for comes back as missing.

• Before: T7.1 builds the tool-calling loop that T12.1 splits in two, and T7.2 packages it as create_agent. The larkspur-handbook server wraps the retriever from T5.1, the one T8 improves. T11.3 ends T11 by pointing at protocols: the coordinator and specialist split stays, and the tools move behind servers.
• Next: T12.2 builds MCP servers and clients with more of the protocol. T12.3 builds MCP applications and RAG over MCP, and T12.4 moves from tools to agents with the A2A protocol.

• Put tools behind a server once and every client can use them; keep the loop, the model choice and the routing in the client.
• Read the definitions FastMCP generates before shipping: the docstring is the description the model sees, and parameter help belongs in the type hints if the model needs it.
• Count what each server costs on every request, and give every tool a name that is unique across all connected servers.
• Choose the transport by where the server runs: stdio for a local subprocess, Streamable HTTP at /mcp for a shared service, with the bind address, session header and auth checked before deploy.