MCP Mastery

1Without MCP, every tool gets wired as many times as there are agents

The course starts from a request made to an assistant: "summarize my Zendesk tickets, add the Salesforce customer record, post the whole thing in Slack". To talk to these three tools, someone hand-writes one connector per tool.

A second assistant arrives, built by another company. It doesn't understand the first one's connectors: all three have to be redone for it. Three tools and three assistants make nine connectors (3 × 3). With ten assistants, thirty.

And they need upkeep. If Salesforce changes its API (the front door programs use to talk to it), the connectors to Salesforce get repaired, one per assistant. Raheja calls these assistants agents: AI programs that chain actions on their own. He sums it up: "the effort doesn't grow with the number of tools, it grows with tools multiplied by agents." (video 2_1).

MCP changes the arithmetic: a common rule that everyone knows, like the USB-C plug, one cable for every device (the course's image). Each tool plugs into it once, each assistant learns it once: 3 + 3 = 6 instead of 9, and 13 instead of 30 with ten assistants.

2Host, client, server: three roles and one client per server

Let's go back to the example. For the common plug to work, the course sets three roles. A role is a job to do, not a specific piece of software: several programs can play the same role.

• host: the application you use, an AI assistant or a code editor. Claude.ai is one, and it is the case in idea 7.
• client: the piece of the host that talks to one server.
• server: the program that offers actions on a tool. A Zendesk server, a Salesforce server, a Slack server. It often just translates: it receives the common request and passes it to the tool through its API.

A client talks to a single server only, like a phone line reserved for one correspondent. Claude.ai wants to reach Zendesk, Salesforce and Slack: it opens three lines, so three clients, all inside Claude.ai (the host).

A server can offer three kinds of building blocks: tools to act, resources to read, prompts to ask. Idea 3 details them.

Usually, the host asks and the server answers. But the server can also need something: it then asks the host, in two ways:

• elicitation: the server needs a piece of information that only the user knows, such as a booking date. It can't see the user, so it goes through the host: the server says "I need the date", the host asks the user, then hands the answer back to the server (my own example).
• sampling: the server needs a text written by a language model, such as a summary, but it has none. It asks the host, which has its own model write it and hands the text back (my own example). The course later declares sampling deprecated (idea 5).

3Act, read, ask: the three building blocks of a server

A server offers three kinds of building blocks, the primitives. Three players can use them. The model is the AI that writes the answers. The application is the program around it: the host of idea 2, like Claude.ai. The third is you, the user. What sets the blocks apart is the intention: to act, to read or to ask. An imagined example, with a Zendesk server:

• Act: that is a tool, such as "create a ticket". The model launches it on its own, by reading its description: what it does and what information to give it.
• Read: that is a resource, a piece of information the server makes available, such as "the list of open tickets". It has an address, like file://… or calendar://…. The application reads it and puts it in front of the model.
• Ask: that is a prompt, a ready-made request such as "summarize my tickets of the week", with blanks to fill in (the week). The user picks it, often from a menu.

What changes from one block to the next is who launches it. Raheja puts it this way: "tools are model controlled, but resources are application controlled." (video 2_3). In other words: the model launches the tools (act), the application launches the resources (read), the user launches the prompts (ask). Why does it matter? Only the tool can change something in the software, like creating or deleting a ticket, on the model's own decision. That is why an application can ask for your consent before a tool runs (video 2_3).

4The MCP message stays the same when the transport changes

What remains is how these blocks travel. An MCP message has two parts:

• The content: what you ask for. It is written in JSON-RPC 2.0. JSON is a text data format, like {"city": "Paris"}. With JSON-RPC, you send a request, which is a question, and the server sends back a response.
• The transport: the path the message takes to arrive.

{"jsonrpc": "2.0", "id": 1, "method": "tools/list"}

My own example: this request asks for the list of the server's tools. It names what you want, here "tools/list". The course presents two standard transports:

• STDIO (standard input and output): the server runs on your computer, launched by the host, with no internet.
• Streamable HTTP: the server is on another computer, reached through a web address (URL). It can answer piece by piece, like a live video.

The course's image: "switching transports is like switching from mail to courier. the letter inside doesn't change." (video 2_4). The letter is the content of the message.

5An MCP revision carries a date, and the date matters

MCP's rules change over time. Each new revision of the specification, the text that defines the protocol, therefore carries a date rather than a number like 1.0 or 1.1. An old client may not understand a recent server (video 2_5). The course relies on the revision of July 28, 2026, which succeeds the one of November 25, 2025. That date names the protocol, not a piece of software like a server in version 1.4.0.

According to the course, the 2026 revision makes the protocol "stateless". The server no longer remembers the conversation: each request carries everything needed to be understood.

It is the difference between a restaurant waiter who knows you and a counter where nobody recognizes you: at the counter, you repeat everything each time. Concretely, each request itself carries the protocol version, the client's identity and its capabilities, what it knows how to do (video 2_5).

The opening of the conversation disappears too. In older tutorials, a handshake opened it with two messages, "initialize" then "initialized". A session ID followed, a number that designated the conversation. Both are gone (video 2_5, confirmed by the course slides).

A deprecated feature still works, but you no longer use it for a new project. It stays for at least twelve months before removal (video 2_5). Video 2_5 lists three deprecated features, and the course slides give the same list: sampling, logging and the old HTTP transport with SSE, replaced by streamable HTTP.

Logging means the server sends the client progress messages. SSE (server-sent events) is a stream of events pushed by the server.

A tutorial written for an old revision may no longer work. One hint: the address (URL) of old servers ends in /sse, that of recent ones in /mcp (video 7_3).

6A live test: the model picks the tool

Ideas 1 to 5 explained the protocol. A practical question remains: when a server offers several tools, who picks the one to use? Idea 3 answers: the model. The course shows it on an example, in n8n, its demonstration tool, which links applications with blocks.

Raheja builds a small MCP server there. Its tools create or delete buckets, storage spaces in Amazon's S3 service. An agent is connected to the address of this server: it is an AI model placed in n8n, with tools at its disposal. You talk to it in a chat.

The test: Raheja starts from 23 buckets, asks for one to be created and counts 24 at the end. The server's log, the list of what it ran, shows that a single tool was used, "create a bucket". Nobody pointed to it by hand: the agent's model picked the tool. Raheja concludes that "it is all decided by MCP server." (video 6_8). I read it differently: the server offers the tools, the model chooses.

The same principle holds with a public server, which you plug in without building anything, by giving its address. Context7 is one: it provides up-to-date documentation for code libraries, pieces of code already written. It helps, because a model only knows what it read before its training (video 7_1). The agent finds the code library's identifier by itself, then its documentation (video 7_2).

7Claude drives n8n, but only what you open to it

This time, n8n is the server. Claude.ai, the host, plugs into it through a client. In Claude.ai, you add n8n by giving the address of its MCP server. Claude then counts the workflows: thirty, seventeen of them running (video 8_1).

To act in n8n, Claude must pass three barriers: three permissions to get. First, consent at connection: a consent screen appears, "Claude requests access to your n8n instance" (your own n8n installation), and you have to accept (video 8_1). Next, access per workflow: for an existing workflow, "Enable MCP access", otherwise Claude answers that it has no access (video 8_2). A workflow that Claude creates is open to it with no setting to change (video 8_3). Last, consent at every tool call, each time Claude runs a tool: "allow once".

Claude thus creates a workflow that lists the S3 buckets, in eight calls approved one by one (video 8_3).