MCP Servers lessons
What is MCP
An AI app wired to four MCP servers; a tool call travels out along one wire and the result comes back into the chat.
MCP stands for Model Context Protocol. It is an open standard that lets AI apps use outside tools and data.
An MCP server offers tools, like checking the weather or opening a GitHub issue. Any AI app that speaks MCP can plug in and use them.
In this course you will connect ready-made servers, read the messages they send and build a server of your own.
One protocol for every tool
Before MCP, every AI app needed custom code for every tool it used. Three apps and four tools meant twelve separate integrations to write and fix.
MCP gives them one shared way to talk. Each app learns MCP once, each tool gets one MCP server, and any app can use any server.
Three apps and four tools, wired directly (12 integrations) or through MCP (7 connections).
People often compare MCP to a USB-C port. One plug shape works with many different devices.
Practice: Count the integrations
Typed answer: apps times tools without MCP, apps plus tools with it. Random numbers each round.
Hosts, clients and servers
The host is the AI app you use, such as Claude Desktop, VS Code or Cursor. It runs the model and decides which tools it may use.
For each server, the host starts a client. A client keeps one connection open to one server, the program that offers tools and data.
A host with three clients, each wired to its own server; the roles light up in turn.
Servers never talk to the model directly. Everything passes through the host, which is how it can ask you before a tool runs.
Practice: Name the role
Match host, client and server to descriptions. Three rounds.
Tools, resources and prompts
A server can offer three kinds of things, called primitives. Tools are actions the model can call, like create_issue.
Resources are data the app can read and pass to the model, like a file. Prompts are ready-made templates that you pick, often from a slash menu.
Three cards: tools, resources and prompts, who chooses each, an example and the methods.
Tools are by far the most used. Many servers offer nothing else.
Practice: Tool, resource or prompt
Multiple choice: is each feature a tool, a resource or a prompt?
The messages underneath
Clients and servers swap small JSON messages in a format called JSON-RPC 2.0. Each request names a method, like tools/call, and has an id.
The reply carries the same id, so the client knows which request it answers. It holds either a result or an error.
Sequence: server/discover, tools/list and tools/call with their replies, and the JSON of each.
Older servers, from before the July 2026 version of MCP, expect an initialize handshake first. Apps and SDKs that support both handle this for you.
Practice: Read a message
Tap the line of a JSON-RPC message that does a given job. Several messages.
Local and remote servers
How the messages travel is called the transport. MCP has two standard ones.
With stdio, the host starts the server as a program on your computer. They swap messages through the program's standard input and output.
With Streamable HTTP, the server runs on the web. Each message is an HTTP POST to one address, like https://example.com/mcp.
Two lanes: stdio on one computer, Streamable HTTP over the web, with messages going down and back.
Practice: Choose the transport
Sort facts into stdio and Streamable HTTP. Two rounds.
Adding a ready-made server
Thousands of servers already exist, for files, GitHub, databases, browsers and more. To add a local one, you list it in your app's config file.
Each entry gives a name, a command that starts the server, its args and any env variables. Save the file, then restart the app.
A claude_desktop_config.json with two servers, walked through part by part.
Remote servers are even simpler. You paste the server's URL into the app's connector settings and sign in.
Practice: Add a secret key
Type the env object that gives a server its API key. Checked as JSON.
Approvals and safety
A local server runs with your permissions, so it can do anything you can. Install servers only from sources you trust, and give each one the least access it needs.
Keep keys in env, never in the chat. Before a tool runs, the host shows you the call so you can allow or deny it.
A fetched web page hides an instruction; the model asks to send an email and you deny it.
Text from a tool can hide instructions for the AI. This is called prompt injection, so treat tool results as data and deny calls you did not ask for.
Practice: Allow or deny
An approval prompt for a tool call: allow it or deny it. Six requests.
Inside a server
You can build a server with an official SDK. For TypeScript, install it with npm install @modelcontextprotocol/server zod.
Each tool gets a name, a description and an input schema listing its arguments. A handler function does the work and returns content.
A complete TypeScript server with one tool, walked through part by part.
Never use console.log in a stdio server, because stdout carries the MCP messages. Log with console.error instead.
Practice: Complete the tool
Fill the gaps in registerTool calls from a bank of pieces. Two rounds.
The same tool in Python
The Python SDK installs with pip install "mcp[cli]". Its MCPServer class, called FastMCP in older versions, builds tools from plain functions.
The function name becomes the tool name and the docstring becomes the description. The type hints become the input schema.
The weather tool written with the Python SDK, walked through part by part.
Testing with the Inspector
The MCP Inspector is a free test app for servers. Run npx @modelcontextprotocol/inspector node build/index.js and it opens in your browser.
It lists your tools and lets you call each one with your own inputs. You see the exact JSON going in and out, with no model in the way.
Terminal: the Inspector CLI lists tools, calls one, then calls it with a bad city and gets isError.
When a tool fails, return a result with isError: true and a clear message. The model reads it and can fix its input and try again.
Practice: Fix the server
Multiple choice: diagnose common problems when building and connecting a server.
Designing good tools
The model picks tools by reading their names and descriptions. Clear names, and descriptions that say when to use the tool, help it pick well.
Give each tool one job and return only what the model needs. Make every error say how to fix the problem.
Vague tools beside clear ones: one job each, clear names and helpful errors.
Practice: Helpful or unhelpful
Sort names, descriptions, errors and results into helpful and unhelpful. Two rounds.
Going remote
To share a server with many people, run it with Streamable HTTP on a web host. People add it with just its URL.
Remote servers usually need a login, and MCP uses OAuth for it. The app opens a sign-in page, you approve, and the app gets an access token.
Flow: request, 401 reply, sign in, token, then every request carries the token.
The app sends the token with every request in an Authorization header. Your password goes only to the sign-in page, never to the AI app.
Practice: Put it in order
Order the OAuth sign-in steps, then the steps to build and connect a server.
Where next
You can now plug servers into an AI app, read their messages and build your own. Try a server for something you use every day, like your notes or a hobby API.
Then add a resource or a prompt, or host it remotely with OAuth. The full spec and SDK guides live at modelcontextprotocol.io.