The problem: M×N integrations

In Topic 2 you gave an agent tools by writing function schemas inside your app. That works, but every tool is bespoke to that app. Now multiply: M AI apps (Claude Desktop, your agent, an IDE, a chatbot) each want to talk to N systems (GitHub, Postgres, Slack, your CRM). Without a standard, that's M×N custom integrations — every app re-implements every connector.

MCP (Model Context Protocol) — an open standard introduced by Anthropic — collapses that to M+N. Each system is wrapped once as an MCP server; each app is an MCP client once. Any client can then use any server. It's "USB-C for AI tools": one protocol, universal connectors. (This is the same protocol behind the ghostcrab, Gmail, and browser tools you use in this very environment.)

Architecture: host, client, server

Three roles:

• Host — the AI application the user interacts with (Claude Desktop, an IDE, your agent). It embeds one or more clients.
• Client — lives inside the host; maintains a 1:1 connection to one server and speaks the protocol.
• Server — a separate process exposing capabilities (tools/resources/prompts) for a specific system.

They communicate over JSON-RPC on a transport: stdio (the server is a local subprocess — most common for local tools) or HTTP (for remote/networked servers). The host's LLM never talks to servers directly; the client mediates every call.

The three server primitives

An MCP server can expose three kinds of capability — this taxonomy is the heart of the protocol:

Primitive	What it is	Who controls it	Analogy
Tools	actions the model can invoke (functions with side effects)	model-driven (the LLM decides to call)	POST endpoints
Resources	read-only data the client can load into context	app-driven (host decides what to load)	GET endpoints / files
Prompts	reusable prompt templates the user can invoke	user-driven (e.g. a slash command)	saved snippets

The distinction matters: tools are for doing (and the model chooses them), resources are for reading (the app supplies them as context), prompts are user-triggered workflows. Most servers start with tools.

Building a server

The Python SDK's FastMCP makes a server almost as simple as writing functions — decorate them and it generates the schemas and protocol plumbing (the schema inference is the same idea as Topic 2, automated):

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather")                       # create a server named "weather"

@mcp.tool()                                     # register a TOOL (a model-invocable action)
def get_forecast(city: str) -> str:
    """Get today's weather forecast for a city."""   # docstring -> the tool description the model reads
    return f"Sunny, 21°C in {city}"             # (a real server would call a weather API)

@mcp.resource("config://units")                 # register a RESOURCE at a URI (read-only context)
def units() -> str:
    """The unit system this server reports in."""
    return "metric (Celsius)"                   # the host can load this into the model's context

if __name__ == "__main__":
    mcp.run()                                    # start the server over stdio (default transport)

The @mcp.tool() decorator inspects the function's signature and docstring to build the JSON schema automatically — the same tool-schema idea from Topic 2, but now the tool lives in a reusable server any MCP client can connect to, not hard-wired into one app.

Consuming a server from a client

A client connects to the server over a transport, lists what it offers, and calls it. Here's the shape with the Python client SDK talking to a stdio server:

from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

params = StdioServerParameters(command="python", args=["weather_server.py"])  # how to launch the server process

async def main():
    async with stdio_client(params) as (read, write):        # spawn the server, get read/write streams
        async with ClientSession(read, write) as session:    # a protocol session over those streams
            await session.initialize()                        # handshake (exchange capabilities/versions)

            tools = await session.list_tools()                # discover what the server exposes
            print([t.name for t in tools.tools])              # -> ['get_forecast']

            result = await session.call_tool("get_forecast", {"city": "Paris"})   # invoke a tool by name + args
            print(result.content)                             # -> "Sunny, 21°C in Paris"

In practice you rarely write this by hand — hosts like Claude Desktop, and agent frameworks (LangChain, LangGraph adapters), consume MCP servers for you from a config file. But knowing the initialize → list → call handshake demystifies what's happening under the hood.

When to build an MCP server vs. a plain tool

MCP is powerful, but it's not free — a server is a separate process, protocol, and deployment. Use the right tool:

• Plain in-process function tool (Topic 2) when the tool is used by one app, is simple, and shares the app's process/lifecycle. No protocol overhead.
• MCP server when the capability should be reused across multiple apps/hosts, needs to run as a separate process (different language, isolation, independent deployment), or you want to plug into the MCP ecosystem (Claude Desktop, IDEs, other agents) without bespoke glue.

The heuristic: one app, one use → function tool; a connector many clients should share → MCP server. The whole point of MCP is reuse and interoperability; if there's nothing to reuse and no other client, a plain function is simpler.

Pitfalls

• Reaching for MCP when a function will do. For a single app's single tool, a plain function tool is simpler — MCP's value is cross-app reuse.
• Confusing tools and resources. Tools are model-invoked actions (side effects); resources are app-loaded read-only context. Modeling a data read as a tool (or vice versa) muddies the design.
• Trusting a server blindly. A server runs code and can act on systems — vet third-party servers as you would any dependency, and scope its permissions (Security track).
• Forgetting the transport choice. stdio for local subprocess tools; HTTP for remote/networked servers — picking wrong complicates deployment.
• Weak tool docstrings. As always, the description drives selection — write server tool docstrings carefully.

Recap

• MCP is an open protocol that turns M×N bespoke integrations into M+N reusable connectors — "USB-C for AI tools."
• Architecture: a host embeds clients, each connected 1:1 to a server, over JSON-RPC on stdio or HTTP.
• Servers expose three primitives: tools (model-invoked actions), resources (app-loaded read-only context), prompts (user-invoked templates).
• Build a server by decorating functions (@mcp.tool(), @mcp.resource()); consume it via the initialize → list → call handshake (usually done for you by the host).
• Choose MCP when a connector should be reused across apps or run as a separate process; a plain function tool when it's one app's single use.
• Worked examples map to the exercises: a server tool (Ex 1), a resource (Ex 2), a client round trip (Ex 3), and the server-vs-function decision (Ex 4).

# notes_server.py
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("notes")
NOTES = {"pricing": "Pro plan is €49/month.", "security": "Encrypted at rest with AES-256."}

@mcp.tool()
def search_notes(query: str) -> str:
    """Search the notes store and return the best matching note."""
    return NOTES.get(query.lower().strip(), "No matching note.")

if __name__ == "__main__":
    mcp.run()   # stdio transport by default

@mcp.resource("notes://index")
def note_index() -> str:
    """The list of available note titles."""
    return ", ".join(NOTES.keys())     # "pricing, security"

import asyncio
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

params = StdioServerParameters(command="python", args=["notes_server.py"])

async def main():
    async with stdio_client(params) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()                          # handshake
            tools = await session.list_tools()
            print("tools:", [t.name for t in tools.tools])      # ['search_notes']
            res = await session.call_tool("search_notes", {"query": "pricing"})
            print("result:", res.content)                       # Pro plan is €49/month.

asyncio.run(main())