Building Your Own MCP Server for AI

What Is MCP?

MCP vs REST APIs, RAG, and function calling — and why a standard host-to-server protocol exists.

An AI assistant is good at language and bad at your private systems. It cannot see your issue tracker, your deploy logs, or yesterday’s invoices unless you give it a door. MCP (Model Context Protocol) is that door: a shared way for a host (Cursor, Claude Desktop, and others) to talk to your server.

You already know other doors. This lesson is about why MCP is not “just another API,” and when you should not use it.

MCP is not your REST API

A REST API is written for programs that already know the contract: GET /tickets/142, status codes, auth headers. A language model does not start with that map. It needs a list of tools, a description of each one, and a JSON schema for arguments. MCP standardizes how the host discovers those tools and how results come back.

You can still wrap a REST API behind MCP. The assistant never has to invent URLs. You choose the verbs. That split is the whole point of Give AI Access to an API.

MCP is not RAG

RAG (retrieval-augmented generation) stuffs documents into the prompt so the model can quote them. It is great for manuals and tickets you already indexed. It is a poor fit for “create the invoice” or “restart the staging worker.” Those are actions. MCP tools are actions (and, later, resources for live data). Many products use both: RAG for reading, MCP for doing.

MCP is not ad-hoc function calling

Vendors already let a model call functions you register in their SDK. That works until you switch hosts. Then you rewrite the glue. MCP puts the server on your side of the wall: one process, many hosts. The host still decides when to call a tool. You decide what exists.

Why MCP exists

  • One protocol for tools, resources, and prompts — not a new plugin format per chat app.
  • The model sees names and descriptions you wrote, not a raw OpenAPI dump unless you choose that.
  • Local stdio servers for a laptop; remote HTTP later for a team. Same idea, different transport.

By the end of this course you will have a Python server the host can launch, a tool it can call, and a path to deploy it. Next: how the pieces connect.