MCP is a specification, not a library

The thing you install is not the thing you are learning

The most common misunderstanding about MCP is that it is something you install. People run pip install mcp, see a Python package, and reasonably conclude that MCP is a Python framework — the way Flask is a Python framework.

It is not. MCP is a document. It specifies a set of JSON-RPC methods, what their parameters mean, what a conforming implementation must do when it receives one, and what it may not do. That document is the protocol. Everything you install is an implementation of it.

This matters practically, not pedantically. A server written in Python and a client written in TypeScript work together, and neither knows the other's language exists. You can implement MCP with no SDK at all, by writing JSON to a pipe — we will read exactly that JSON in Lesson 6, and it is short enough to write by hand. And when you hit something the Python SDK does not expose, the spec is the place to look, because the SDK is a convenience over the document and the document is the authority.

HTTP and requests

Nobody confuses HTTP with the requests library. HTTP is the agreement about what GET /rooms means and what a 404 says; requests is one pleasant way to speak it in one language. You can speak HTTP with curl, with a socket, with any of forty libraries — and a Python client talks to a Go server without either caring.

MCP sits in exactly that relationship to the SDK you are about to install. The Python SDK is requests. The specification is HTTP. When this course says "MCP requires", it means the document; when it says "the SDK does", it means one implementation's choice, and a different SDK might reasonably choose otherwise.

What the specification actually specifies

Concretely, the spec pins down four things.

• A message format. MCP messages are JSON-RPC 2.0 — a request carries a method, a params object and an id; a response carries the same id and either a result or an error. Nothing is invented here; JSON-RPC has been around since 2005 and MCP uses it as-is.
• A set of methods. tools/list, tools/call, resources/list, resources/read, prompts/list, prompts/get, server/discover, and a handful more. The method names and their shapes are the protocol's surface area.
• What the parameters mean. That a tool's input_schema is JSON Schema and that a client may validate against it; that a resource is addressed by URI; that a tools/call result is a list of content blocks.
• Obligations. What a server must implement (server/discover), what it must not do (accept a token issued for somebody else), what a client should do before opening a URL a server handed it.

Here is a real tools/list result from the server you will build. This is MCP — not the Python that produced it:

{
  "name": "find_slots",
  "title": "Find free slots",
  "description": "Free slots in a room on a given day. Call this before booking anything.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "room_id": {"description": "Room id: atrium, studio-b or nook.", "title": "Room Id", "type": "string"},
      "day": {"description": "The day to search, as YYYY-MM-DD.", "title": "Day", "type": "string"},
      "minutes": {"default": 60, "enum": [30, 60, 120], "title": "Minutes", "type": "integer"}
    },
    "required": ["room_id", "day"],
    "title": "find_slotsArguments"
  }
}

A client receiving that knows how to call the tool, and knows it without having read a line of our source. That is the whole trick.

The version string is a date

MCP versions look like 2026-07-28, and readers reliably try to compare them numerically or ask which one is "2.0". They are dates, not semantic versions. 2026-07-28 is simply the revision published on that day, and the one this course teaches.

The Python SDK versions separately and does use semver — this course uses SDK v2, which implements spec 2026-07-28. Two version numbers that mean different things is a small tax, but conflating them is the source of a lot of confused searching.

Who owns it

MCP was created by Anthropic and released in November 2024 under the MIT licence. It is now governed as a community project, with a public proposal process (SEPs) through which changes are argued in the open, and an ecosystem of implementations from companies with no relationship to Anthropic.

This is worth stating plainly because "an AI company published a protocol for talking to AI applications" invites a reasonable suspicion of lock-in. The protocol does not mention a model vendor anywhere. A server you write works with any client; a client you write works with any server. The document is the product, and the document is free.

What to take into the next lesson

MCP is a specification, not a library — a document defining JSON-RPC methods and their meanings, which any language can implement and which the SDK merely makes pleasant. Version strings are dates, the licence is MIT, and governance is communal. Next: the three things a server can offer, and the single question that tells you which one you are building.