In module T7, the quote agent got tools: methods in your code that the model may call. Only your agent knows these tools. If the chat in VS Code should also know which appointments are in the Kladde tomorrow, or if a second agent should, you'd have to build the same methods in there again. The Model Context Protocol (MCP) solves exactly that: A program offers its tools through an open protocol, and every client that speaks MCP can use them.
In this module, you build both sides. In this lesson, an MCP server is created that can read the Kladde's contacts and appointments. In the next, the quote agent uses it as a client. In the third, the server gets a path over HTTP, a sign-in and permissions per tool. The examples ran with these packages:
| Package | Version |
|---|---|
ModelContextProtocol |
2.4.0 |
Microsoft.Extensions.Hosting |
10.0.14 |
xunit.v3.mtp-v2 |
4.0.2 |
The tool descriptions, error sentences and test data in the code of this module are German, as the prompts in module T3 were. A model that works in German reads them, and the tests compare some of them letter by letter. Wherever a sentence matters, the text says what it means.
What MCP is
MCP describes how a client talks to a server. The client sits in an application with a language model, for example in VS Code or in your agent. In MCP, this application is called the host. It has a client of its own for every server it uses. The server offers capabilities. The messages between the two are JSON according to JSON-RPC 2.0: a request with a method and parameters, a response with a result or an error.
A server can offer three kinds of capabilities. They differ in who decides when they are used:
| Kind | What it is | Who decides | Example in the Kladde |
|---|---|---|---|
| Tool | a function with parameters and a result | the model, as with function calling in T7 | "Find contacts", "Appointments of a day" |
| Resource | data at an address (URI), such as a file | the application, which passes it to the model | the Kladde's house rules as Markdown |
| Prompt | a template for a message, with parameters | the person who picks it in the application | "Weekly overview for Monday, ..." |
In the Kladde, the focus is on tools, because the agent uses them. Resources and prompts work in the C# SDK by the same pattern, with
attributes of their own ([McpServerResourceType], [McpServerPromptType]); the links at the end show them.
For the path of the messages, MCP knows two transports:
- stdio: The client starts the server as a process of its own on the same machine. It writes the messages to the server's standard input, one message per line, and reads the answers from its standard output. The server runs with the rights of the person who starts the client and needs no sign-in. This is the path for tools on your own machine.
- Streamable HTTP: The server is a web service with a single endpoint. The client sends every message as a
POST, and the answer comes as JSON or as a stream (server-sent events). Many clients can use it at the same time, even over the network. That's why it needs a sign-in and permissions, and that's what T8.3 is about.
The sequence is always the same. First the client learns which version of the protocol the server speaks and what it can do. In the older
versions, this happens in a handshake called initialize; in the newest, the client asks with server/discover, and after that every
request carries along which version it speaks. Which way it takes is negotiated by the SDK. Then the client asks for the list of tools with
tools/list, with names, descriptions and the JSON schema of the parameters. The application gives this list to the model. When the model
picks a tool, the client sends tools/call with the name and the arguments.
There's one thing MCP doesn't do: It doesn't make anything safe. It's a pipe. What a tool may do, what it hands out and whom you trust with a server is for you to decide. That's what all three lessons are about.