Loading...
System Design and AI Engineering, by Roni Das. 980 interactive lessons.
Start LearningAI Engineering · Advanced · LLM and GenAI Ops
An open protocol that lets AI apps such as Claude, ChatGPT, Cursor and VS Code use outside tools and data. An MCP server offers the tools once, and any app with an MCP client can find and call them.
In short
An MCP server is a small program that gives AI apps such as Claude, ChatGPT, Cursor and VS Code a set of tools, data and prompt templates through the Model Context Protocol (MCP), an open standard. You write the server once, and any app that speaks MCP can find its tools and call them.
In short
An MCP server is a small program that gives AI apps such as Claude, ChatGPT, Cursor and VS Code a set of tools, data and prompt templates through the Model Context Protocol (MCP), an open standard. You write the server once, and any app that speaks MCP can find its tools and call them.
Learn it in the course
This page is the free part.
₹999 in India$49 everywhere elseonce, for the whole course
The AI Engineering course covers MCP across a run of lessons, not one page. These 4 alone are about 211 minutes of step-by-step reading, every one with code you run in the browser, all with a quiz.
MCP turns N times M tool integrations into N plus M, but every attached server rents context-window tokens on every request. When it pays, when it does not.
Your LLM app loads weights, datasets, packages, and MCP servers you never wrote. Pin, hash, scan, sign, and verify provenance so an import cannot own you.
The model never runs your functions. It emits text proposing a call, and sometimes that text is wrong. How to validate every tool call against a schema before it runs, and reject cleanly so the model self-corrects.
Two small models, 60 requests, each offered 5 to 100 tools. Picking the right tool barely suffered until 100 tools, and look-alikes alone did no harm. The bigger problems were elsewhere: right choices written as broken JSON, valid calls that Ollama's chat API silently dropped, and replies that took 13 times longer with every tool on offer.
all part of
AI Engineering
210 lessons · about 219 hours · 10 free to read
₹999in India, by UPI
$49everywhere else, by PayPal
You own this course
Continue with MCP in Production: What the Protocol Buys and Costspay once,
yours for life
An MCP server is a program that offers an AI app three kinds of things: tools it can run, data it can read, and ready-made prompts. It offers them through MCP, the Model Context Protocol. Anthropic published MCP as an open standard in November 2024, and in December 2025 handed it to the Agentic AI Foundation, a fund under the Linux Foundation, so no single company owns it.
A few words first. A protocol is an agreed set of messages, like the rules two people follow on a phone call. A tool is a function the model can ask to run, such as "search GitHub issues" or "look up an order". The model is the language model that writes the reply; on its own it can only produce text, so tools are how it gets things done in the world.
The word server confuses people. An MCP server does not have to be a machine in a data centre. Most of the MCP servers people use today are a small program on their own laptop, started by the AI app itself. Some run on the internet, like any web service, and many people can share one.
MCP is the rulebook. An MCP server is one program that follows it. An MCP client is the part of the AI app that talks to a server. Keep those three apart and the rest of this page is easy.
Before MCP, every AI app that wanted to use GitHub wrote its own GitHub code: its own login handling, its own way of describing the functions to the model, its own error handling. Then it did the same for Postgres, and again for Slack. Three apps and three tools meant nine separate connectors, and every time one tool changed its API, three of them broke.
MCP turns that grid into two short lists. Each app builds one MCP client. Each tool ships one MCP server. Any client can then use any server, so a fourth app needs one new client, not three new connectors, and a fourth tool needs one new server that every app can use straight away.
What MCP saves is the wiring code. It does not make tools free to run. Every server you attach still sends its tool descriptions to the model on every request, and still asks you to trust it. Both costs are covered further down.
The specification names three roles. They matter because they tell you where each check belongs.
One thing to hold onto: the model never talks to a server. The model can only ask, in text, for a tool to be run. The host reads that request, the client sends it, the server runs it, and the result comes back the same way. That gap between asking and running is where you validate arguments and where a person can say no.
MCP messages are JSON-RPC 2.0. That is a small, old format for calling a function on another program: each message is a JSON object with a method name, some parameters and an id, and the answer carries the same id so the client knows which question it answers.
Here is one tool use from start to finish, taken from the real messages my test server and client exchanged. The client first asks the server which protocol versions it speaks and what it can do (server/discover). Then it asks for the list of tools (tools/list) and gets back each tool's name, a description in plain words, and a JSON schema for its arguments. The host puts the user's question and those tool descriptions in front of the model. When the model asks for a tool, the client sends tools/call with the arguments, the server runs the function, and the result goes back to the model, which writes the answer.
Captured on stdio, 2026-07-28 protocol: the tools/call request and its answer (-> client to server, <- server to client)
-> {"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"define","arguments":{"term":"MCP"},"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientInfo":{"name":"mcp","version":"0.1.0"},"io.modelcontextprotocol/clientCapabilities":{}}}}
<- {"jsonrpc":"2.0","id":3,"result":{"content":[{"text":"A protocol that lets AI apps use outside tools and data.","type":"text"}],"isError":false,"resultType":"complete","structuredContent":{"result":"A protocol that lets AI apps use outside tools and data."},"_meta":{"io.modelcontextprotocol/serverInfo":{"name":"glossary","version":""}}}}The same server in the older handshake era (2025-11-25): the first three messages
-> {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"mcp","version":"0.1.0"}}}
<- {"jsonrpc":"2.0","id":1,"result":{"capabilities":{"prompts":{"listChanged":false},"resources":{"listChanged":false,"subscribe":false},"tools":{"listChanged":false}},"protocolVersion":"2025-11-25","serverInfo":{"name":"glossary","version":""}}}
-> {"jsonrpc":"2.0","method":"notifications/initialized"}Most MCP tutorials still show the second picture. Up to the 2025-11-25 version of the specification, every connection opened with a handshake: the client sent initialize, the server answered with its version and capabilities, and the client confirmed with notifications/initialized. The current version, 2026-07-28, removed that handshake. Every request now carries the protocol version and the client's capabilities in a _meta field, which you can see in the first capture, and a client may call server/discover first to learn what the server supports.
Both eras are live. The official Python SDK tries server/discover and falls back to the handshake when a server is older. The MCP Inspector 2.9.0 I used still connects with the handshake, and labels its message log LEGACY. My MCP in Production lesson walks through the handshake version of this flow and what each step costs.
A transport is the wire the JSON messages travel on. MCP defines two.
http_client.py: the same SDK client, pointed at a URL instead of a command
import asyncio
from mcp import Client
async def main() -> None:
async with Client("http://127.0.0.1:8000/mcp") as client:
result = await client.call_tool("word_count", {"text": "one protocol, many tools"})
print("word_count ->", result.structured_content)
asyncio.run(main())Server in one terminal, client in another, run on 2026-10-04
$ .venv/bin/mcp run server.py --transport streamable-http
$ .venv/bin/python http_client.py
word_count -> {'result': 4}If you read about an "HTTP with SSE" transport with two separate endpoints, that is the original 2024 design. It has been deprecated since the 2025-03-26 version. For logging in, HTTP servers use OAuth 2.1, and the specification says a stdio server should read its credentials from environment variables instead.
A server can offer three kinds of thing. The difference between them is who decides when each one is used.
Servers can also ask the user a question through the app, which the specification calls elicitation. Two older client features, sampling (a server asking the host's model to write something) and roots (the host telling a server which folders it may touch), are deprecated in the 2026-07-28 version, so new servers should not depend on them.
This is the smallest useful server I could write: two tools and one resource, with the official Python SDK. I ran every command below on a Mac on 2026-10-04 and copied the output as it came out. You need Python 3.10 or newer; I used uv to make a virtual environment, but plain pip works the same.
A warning before you copy older tutorials: if one says from mcp.server.fastmcp import FastMCP, it was written for version 1 of the SDK. Version 2 (2.3.0 on PyPI when I ran this) renamed FastMCP to MCPServer, and the old import now fails with ModuleNotFoundError.
Install
uv venv --python 3.12 .venv
uv pip install --python .venv/bin/python "mcp[cli]"server.py
from mcp.server import MCPServer
mcp = MCPServer("glossary")
TERMS = {"mcp": "A protocol that lets AI apps use outside tools and data.",
"latency": "The time between asking and getting an answer."}
@mcp.tool()
def define(term: str) -> str:
"""Look up a term in the glossary."""
return TERMS.get(term.lower(), f"No entry for {term!r}.")
@mcp.tool()
def word_count(text: str) -> int:
"""Count the words in a piece of text."""
return len(text.split())
@mcp.resource("glossary://terms")
def all_terms() -> str:
"""Every term this server knows, one per line."""
return "\n".join(sorted(TERMS))
if __name__ == "__main__":
mcp.run()client.py: starts server.py over stdio, lists the tools, calls one, reads the resource
import asyncio, sys
from mcp import Client, StdioServerParameters
async def main(mode: str) -> None:
server = StdioServerParameters(command=sys.executable, args=["server.py"])
async with Client(server, mode=mode) as client:
tools = await client.list_tools()
for t in tools.tools:
print("tool:", t.name, "-", t.description)
result = await client.call_tool("define", {"term": "MCP"})
print("define('MCP') ->", result.content[0].text)
res = await client.read_resource("glossary://terms")
print("glossary://terms ->", res.contents[0].text.replace("\n", ", "))
asyncio.run(main(sys.argv[1] if len(sys.argv) > 1 else "auto"))Output of .venv/bin/python client.py
tool: define - Look up a term in the glossary.
tool: word_count - Count the words in a piece of text.
define('MCP') -> A protocol that lets AI apps use outside tools and data.
glossary://terms -> latency, mcpThe same server tested with the official MCP Inspector, in command-line mode
$ npx -y @modelcontextprotocol/inspector@2.9.0 --cli .venv/bin/python server.py \
--method tools/call --tool-name word_count --tool-arg "text=one protocol many tools"
{
"content": [
{
"type": "text",
"text": "4"
}
],
"structuredContent": {
"result": 4
},
"isError": false
}
Notice what I did not write. There is no JSON schema in server.py: the SDK built one from the type hint term: str, and you can see it in what tools/list returned: an input schema with one required string called term. The docstring became the description the model reads. That description is the most important line in the file, because it is all the model knows about when to use your tool.
To poke at your own server by hand, run npx @modelcontextprotocol/inspector .venv/bin/python server.py. It starts a local web page where you can connect, list tools and call them, as in the screenshot.
Each app keeps a small JSON file that lists the servers to start. Use full paths, so the app can find Python and your file whatever folder it starts in, and restart the app after you edit the file. I tested the server above with the SDK client and the Inspector. I did not script these apps here, so the file names and shapes below come from each vendor's own documentation, checked on 2026-10-04 and linked under Sources.
Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows
{
"mcpServers": {
"glossary": {
"command": "/Users/you/mcp-glossary/.venv/bin/python",
"args": ["/Users/you/mcp-glossary/server.py"]
}
}
}Cursor: .cursor/mcp.json in the project, or ~/.cursor/mcp.json for every project
{
"mcpServers": {
"glossary": {
"command": "/Users/you/mcp-glossary/.venv/bin/python",
"args": ["/Users/you/mcp-glossary/server.py"]
}
}
}VS Code: .vscode/mcp.json uses a "servers" key (VS Code now also reads a workspace .mcp.json with "mcpServers")
{
"servers": {
"glossary": {
"command": "/Users/you/mcp-glossary/.venv/bin/python",
"args": ["/Users/you/mcp-glossary/server.py"]
}
}
}ChatGPT works differently. In developer mode it connects to remote MCP servers over HTTP, so it needs a URL, not a command on your laptop. Run the server with the Streamable HTTP transport somewhere ChatGPT can reach, and put proper login in front of it before you do.
Everything an MCP server sends back is text, and the model reads all of it in the same stream as your own instructions. It has no reliable way to tell which sentences came from you and which came from a stranger. That is the root of every MCP security problem.
Two kinds of server text reach the model. Tool descriptions are sent on every request, and people review them once, at install, if at all; a malicious or later-changed description can tell the model to read a private file and pass it along. Researchers at Invariant Labs called that tool poisoning in April 2025. Tool results are the second kind: a GitHub issue, a web page or an email the tool fetched can carry an instruction someone planted there. Both are forms of prompt injection. My MCP security lesson argues the description is the boundary teams forget, because they already distrust outputs.
The danger peaks when one agent has three things at once: access to your private data, exposure to text a stranger wrote, and a way to send data out. Simon Willison named this the lethal trifecta in June 2025, and his example was a real exploit through GitHub's official MCP server. Take away any one of the three and the theft has nowhere to go. I build the attack and the fix step by step in Prompt Injection and the Lethal Trifecta.
Not every MCP bug goes through the model. A server is software running on your machine. CVE-2025-6514 (rated 9.6) let a malicious server run commands through the mcp-remote proxy in versions 0.0.5 to 0.1.15, fixed in 0.1.16. CVE-2025-49596 let a web page attack MCP Inspector before 0.14.1. Patch your MCP tooling like any other dependency.
None of these depend on the model spotting an attack, which it cannot do reliably. They limit what a fooled model can reach.
The model does not remember anything between requests, so the host sends the full tool list from every attached server each time. A tool with a detailed schema can take around a thousand tokens; the MCP project tracks this in the open as specification issue 2808. Twenty attached tools can fill tens of thousands of tokens before the user has typed a word, and the model chooses worse when it has more tools to choose from.
Prompt caching lowers the price of that repeated block, but it does not give the context window back and it does not make the choice easier. Attach the servers a task needs, not every server you own. The MCP in Production lesson prices this for a real agent and shows where the line falls.
MCP pays when many apps share the same capability, or when a maintained server already exists for a tool you need and connecting to it is less work than writing and owning that code.
It does not pay for one app with a few functions you wrote yourself. Call them directly, check their arguments against a schema, and you skip the extra process or network hop, the extra description tokens, and a server to version and secure. Reach for the protocol when the reuse is real, not because it is the standard.
Claude Desktop and Claude Code
Anthropic's apps are MCP hosts. Claude Desktop starts local servers listed in claude_desktop_config.json.
ChatGPT
Developer mode connects ChatGPT to remote MCP servers over HTTP, including tools that write, not only read.
VS Code and Cursor
Both code editors are MCP hosts and read servers from a JSON file in your project or home folder.
GitHub MCP server
GitHub maintains its own server for issues, pull requests and code. The early reference GitHub server has been archived.
Reference servers
The modelcontextprotocol/servers repository keeps Filesystem, Git, Fetch, Memory, Time, Sequential Thinking and Everything as examples to learn from.
MCP Inspector
The official tool for testing a server by hand, in a browser or from the command line, as used on this page.
An API is written for programmers: each one has its own URLs, login and data shapes, and someone writes code to use it. An MCP server is written for AI apps: it describes its tools in plain words and a JSON schema, in one standard format, so any MCP app can find them and let a model call them. Many MCP servers are a thin layer over an existing API.
It is a real program, but often not a server in the data-centre sense. Most local MCP servers are a small process that the AI app starts on your own computer and talks to over standard input and output. Remote MCP servers do run as web services, reached over HTTP like any other.
MCP is the protocol: the rulebook for the messages. An MCP server is a program that follows it to offer tools, data and prompts. An MCP client is the connector inside an AI app that talks to one server; the app creates one client per server it uses.
Yes. OpenAI supports MCP, and ChatGPT's developer mode can connect to remote MCP servers over HTTP, including tools that change data. It cannot start a program on your laptop the way Claude Desktop does, so the server needs a URL.
RAG, retrieval-augmented generation, is a technique: search your documents and put the best passages in the prompt. MCP is a way to plug tools and data into an AI app. They work together: a search tool or a document resource on an MCP server is one common way to do the retrieval step of RAG.
Function calling is the model's side: given tool definitions, it replies with a request to call one. MCP is how those tools are packaged and delivered: a server describes them once and any MCP app can load them. The model still only asks, and your app should still check every call. See tool calling.
Often not. Many companies ship official servers for their products, such as GitHub, and the MCP project keeps reference servers for files, Git, web fetching and memory. Build your own when you need your own data or functions, and check who publishes any server you install, since it runs with your permissions.
Checked against these on .
Design an AI Agent Platform
Design a production AI agent orchestration platform - MCP, A2A protocol, tool calling, memory systems, multi-agent workflows, cost management, and safety guardrails
AI Supply Chain Security: What You Import Runs as You
Your LLM app loads weights, datasets, packages, and MCP servers you never wrote. Pin, hash, scan, sign, and verify provenance so an import cannot own you.
Tool Calling Is a Contract, and the Model Will Break It
The model never runs your functions. It emits text proposing a call, and sometimes that text is wrong. How to validate every tool call against a schema before it runs, and reject cleanly so the model self-corrects.
Too Many Tools, or Tools That Look Alike? Measuring How Agents Pick
Two small models, 60 requests, each offered 5 to 100 tools. Picking the right tool barely suffered until 100 tools, and look-alikes alone did no harm. The bigger problems were elsewhere: right choices written as broken JSON, valid calls that Ollama's chat API silently dropped, and replies that took 13 times longer with every tool on offer.
MCP Security: Tool Poisoning, Rug Pulls, and the Confused Deputy
In MCP the trust boundary is the tool description, not the output. Learn tool poisoning, rug pulls, shadowing, confused deputy, and the defenses that hold.
Tool Calling
When a model emits a structured request to run a function, and an orchestrator executes it and feeds the result back. The model never runs anything itself, so the orchestrator validates every call.
AI Agent
A language model placed in a loop: it decides an action, calls a tool, reads the result, and repeats until done. The hard part is that per-step errors compound over many steps.
Prompt Injection
An attack where untrusted text, often returned by a tool, carries an instruction the model obeys, because the model cannot reliably tell instructions from data. The top security risk for agents, and unsolved by prompting alone.
Lethal Trifecta
The dangerous combination of access to private data, exposure to untrusted content, and a way to exfiltrate. An agent with all three can be turned against its own user by a prompt injection.
Context Engineering
Deciding what goes into a model's limited context window and in what order. Production data shows quality degrades well before the advertised token limit, so what you leave out matters as much as what you put in.
RAG (Retrieval-Augmented Generation)
A pattern that retrieves relevant text from an external index and puts it in the model's prompt so the answer is grounded in current, verifiable facts rather than the model's memory.
This page explains the idea. The "MCP in Production: What the Protocol Buys and Costs" lesson builds it up step by step, with diagrams. It is part of the AI Engineering course, which has 210 lessons. 10 of them are free to read. You pay once and keep it for life, with no subscription.
Open the MCP in Production: What the Protocol Buys and Costs lessoncourse 2
Take models from notebook to production, with labs on real models.