Lesson 1: What MCP Is and What This Course Is

Before we start: what this course is

This course is independent of Anthropic. Anthropic did not produce, sponsor or endorse it, and it does not reproduce Anthropic's course or documentation text. Claude products appear later only as examples of software that speaks the protocol.

The Model Context Protocol (MCP) is not one vendor's product feature. It is an open standard for connecting AI applications to external systems. Anthropic open-sourced it in November 2024 and, on 9 December 2025, donated it to the Agentic AI Foundation, which sits under the Linux Foundation. Three facts about how it is run today:

• Seats belong to people. Maintainer roles are held by individuals, and no company has a reserved seat.
• Changes go through a public process. Specification changes are proposed as Specification Enhancement Proposals (SEPs).
• The licence is open. Code and specification contributions are made under Apache 2.0.

For you this means a server you write is not tied to one assistant. ChatGPT, Claude, Visual Studio Code and Cursor are all listed by the MCP project as supporting it.

The problem: every pairing needs its own glue

You have used an assistant with tools, so you know the pattern: describe a function to the model, the model asks for it, your code runs it. The catch is that every model API wants that description in its own shape.

Here is the same tool written for two vendors:

# One tool, described for Anthropic's Messages API
anthropic_tool = {
    "name": "get_invoice",
    "description": "Fetch one invoice by its ID.",
    "input_schema": {                      # <- snake_case key
        "type": "object",
        "properties": {"invoice_id": {"type": "string"}},
        "required": ["invoice_id"],
    },
}

# The same tool, described for OpenAI's Responses API
openai_tool = {
    "type": "function",                    # <- extra discriminator
    "name": "get_invoice",
    "description": "Fetch one invoice by its ID.",
    "parameters": {                        # <- different key again
        "type": "object",
        "properties": {"invoice_id": {"type": "string"}},
        "required": ["invoice_id"],
    },
}

The schema inside is identical, but the wrapper is not, and neither is the reply. One API hands you a tool_use block and expects a tool_result. The other hands you a function_call item and expects a function_call_output.

That is only the format. Each integration also needs its own authentication, error handling and deployment inside each assistant's plugin system. Now count the work:

assistants = 4   # the AI apps your users actually use
tools      = 6   # invoices, tickets, wiki, CRM, calendar, deploys

assistants * tools   # 24 custom integrations: one per pairing
assistants + tools   # 10 implementations with a shared protocol:
                     #   each assistant learns the protocol once,
                     #   each tool is wrapped once

Add a seventh tool. Without a shared protocol that is four new integrations. With one, it is a single wrapper, and every assistant can use it.

You have seen this fix before. The Language Server Protocol did the same for editors and programming languages, and USB did it for peripherals. The MCP project itself uses the USB-C comparison.

What the shared protocol looks like

In MCP the program that offers the tools is called a server. The next level makes the roles precise. A server describes each tool once, in one neutral shape:

# How an MCP server advertises the tool (one entry in a tools/list result)
mcp_tool = {
    "name": "get_invoice",
    "description": "Fetch one invoice by its ID.",
    "inputSchema": {                       # camelCase: MCP's own spelling
        "type": "object",
        "properties": {"invoice_id": {"type": "string"}},
        "required": ["invoice_id"],
    },
}

Any MCP-speaking application calls it the same way, with a JSON-RPC message:

# Application -> server (trimmed: real requests carry some extra metadata)
request = {
    "jsonrpc": "2.0", "id": 2,
    "method": "tools/call",
    "params": {"name": "get_invoice", "arguments": {"invoice_id": "INV-1042"}},
}

# Server -> application (trimmed)
response = {
    "jsonrpc": "2.0", "id": 2,
    "result": {
        "content": [{"type": "text", "text": "INV-1042: 480.00 EUR, unpaid"}],
        "isError": False,
    },
}

You will not hand-write these messages. The Python and TypeScript SDKs generate them, and later levels take the messages apart field by field.

MCP is not function calling

This is the distinction people most often blur. The two solve different halves of the problem and sit on different sides of your application.

   model  <── function calling ──>  application  <── MCP ──>  server (tools)
          (the vendor's model API)               (open protocol)

• Function calling is how the application and the model talk about tools. It is part of each vendor's model API, with the differences you saw above.
• MCP is how the application and the tool provider talk. It is the same whichever model is in use.

One turn, end to end:

1. The application asks the MCP server which tools it has (tools/list).
2. It translates those definitions into the model API's format and sends them with the user's message.
3. The model replies with a function call: get_invoice, INV-1042.
4. The application turns that into an MCP tools/call request to the server.
5. The server runs the code and returns a result.
6. The application passes the result back to the model through function calling, and the model writes the answer.

Gotcha: the model never speaks MCP. It sees tool definitions and emits tool calls in its API's format. The application translates in both directions. So MCP does not replace function calling; it standardises the other side of the application.

Trade-off: if you own one script, one model and three functions, plain function calling is less machinery, and that is fine. MCP earns its keep when a tool must work in applications you do not control, or when several applications share it.

Pitfall: "supports MCP" does not mean "supports all of MCP". Applications implement different subsets of the protocol, so a shared standard reduces integration work without removing the need to test.

Key takeaways

• This course is independent of Anthropic.
• MCP is an open standard governed under the Linux Foundation's Agentic AI Foundation, with maintainer seats held by individuals.
• Without a shared protocol, integrations grow as assistants × tools. With one, they grow as assistants + tools.
• Function calling sits between the application and the model. MCP sits between the application and the tool provider.
• The model never sees MCP. The application translates between the two.
• For one application with a few private functions, plain function calling is enough.