Model Context Protocol (MCP)

You've felt this pain even if you've never named it. Your team ships a support agent that reads from your ticketing system. A month later a second team wants their coding assistant to read the same tickets — so they write the integration again, slightly differently. Then someone builds a Slack bot, and it needs the tickets too. Three apps, one data source, three hand-rolled connectors that all drift apart, all break separately, all need re-auth when the ticket API changes. Now multiply that across every data source your org has. That quiet, compounding mess is exactly what MCP exists to kill.

The clean way to see it is with a plug analogy. Before USB, every device had its own cable — printer cables, mouse connectors, serial ports, each incompatible with the others. USB won because it was one contract: any device that speaks USB works in any port that speaks USB, and neither side has to know anything about the other's internals. MCP is USB for AI tools. It's an open protocol — a fixed, published set of rules — for how an LLM application asks an external program "what can you do, and do it." Once both sides speak the protocol, they interoperate without bespoke glue.

Here's the precise idea the section is built around. Call the number of AI applications N and the number of tools/data sources M. In the old world, each app needs a custom connector to each tool, so you build and maintain N × M integrations — and that product explodes: it's the multiplication rule from the complexity track, and doubling either side roughly doubles the work. A protocol changes the math. Each app implements the standard once (that's N), and each tool is wrapped as an MCP server once (that's M), giving N + M total. Addition, not multiplication.

The common mistake here is dismissing this as "just an interface" — a nice-to-have abstraction. It isn't cosmetic; it's the difference between an integration cost that grows like an area and one that grows like a perimeter. At small scale (2 apps, 2 tools) both look the same. At org scale the gap is brutal: 20 apps and 20 tools is 400 bespoke connectors versus 40 standardized ones. The protocol doesn't make any single integration cleverer — it makes each one reusable, which is what turns a quadratic problem into a linear one. Keep that N×M-versus-N+M lens in mind; the diagram and the tiny program below both exist to make it something you can feel rather than just recite.

1 · Why a protocol at all essential

Before MCP, every AI app wrote custom integrations for each tool and data source — N apps × M tools = N×M bespoke connectors. A protocol collapses that: build a tool once as an MCP server (M servers), and any client speaks to all of them (N clients). N+M, not N×M.

nxm.pydef integrations(n_clients, m_tools, with_protocol):
    return (n_clients + m_tools) if with_protocol else (n_clients * m_tools)

print("5 apps x 8 tools, custom:  ", integrations(5, 8, False), "integrations to build/maintain")
print("5 apps x 8 tools, via MCP: ", integrations(5, 8, True), "(each side implements the standard once)")

5 apps x 8 tools, custom:   40 integrations to build/maintain
5 apps x 8 tools, via MCP:  13 (each side implements the standard once)

2 · MCP vs function-calling vs plugins essential

If you've read Ch 4, a fair objection is forming in your head right now: "Wait — I already gave the model tools. I wrote a JSON schema, the model asked to call get_weather, I ran the function and handed back the result. Didn't I already solve this?" You did — for one app. The confusion between function-calling and MCP is the single most common misunderstanding on this topic, and clearing it up is the whole job of this section.

Think of it as the difference between a skill and a marketplace. Function-calling is the model's built-in ability to say "I'd like to call this tool with these arguments." That ability is real and necessary — but the tool definitions live inside your one application's code. If another team wants the same tool, they copy your schema and re-wire the execution. Nothing is shared. MCP sits one layer up: it's the marketplace where tools are published once and any application can walk in and use them. Crucially, MCP doesn't replace function-calling — under the hood, when the model picks an MCP tool, the app still uses ordinary function-calling to invoke it. MCP just standardizes where the tools come from and how they're described.

The table below sorts three approaches you'll hear conflated. Read it along the "reusable across clients?" column, because that's the axis that actually matters. Function calling is app-specific: powerful, but every app re-implements its tools. Vendor plugins (the closed app-store style) are reusable, but only inside one vendor's walled garden — build a plugin for vendor A and it does nothing for vendor B. MCP is the only row that's both reusable and open: any compliant client can talk to any compliant server, regardless of who made either. The mistake to avoid is treating these as competitors to pick between — in practice a real system uses function-calling as the mechanism, MCP as the distribution model, and skips vendor plugins precisely because of the lock-in the third row warns about.

3 · Intermediate — the architecture intermediate

Here's where beginners tie themselves in knots: the word "server" makes people picture a machine in a data center, and "client" makes them picture a browser. Drop that image — in MCP these words describe roles in a conversation, not big remote boxes. An MCP server is often just a small script running on your own laptop; an MCP client is a component living inside the AI app you're already using. Once you see them as two programs talking, the architecture stops being intimidating.

The clean mental model has three named parts. The host is the AI application the human interacts with — Claude Code, a chat UI, your own agent. The host embeds one or more clients, and each client holds a single connection to one server. The server is the program that actually owns a capability: it wraps a filesystem, a database, GitHub, whatever. So the shape is one host → many clients → one server each. Why split "host" from "client" at all? Because the host can juggle several servers at once (one for your files, one for your database, one for Slack), and each gets its own dedicated client connection — like a restaurant host who seats you while separate waiters handle separate tables.

The sequence matters, and it's the part to actually remember. When a client connects to a server it doesn't immediately start calling things — it first discovers what the server offers: its tools, its resources, its prompts (the three primitives you'll meet next). The client collects those advertised capabilities and hands the model a menu. Then, when the model decides to use something, the client routes that call to the server that owns it and relays the result back. Discover, then route — that two-step is the entire runtime loop. The common mistake is to imagine the model talking directly to the server; it never does. The model only ever produces a request ("call create_ticket with these args"), and the client is the intermediary that knows which server that request belongs to. Hold onto that separation — it's exactly what the capability-discovery section builds on next.

MCP is client-server. The host app (Claude Code) runs an MCP client that connects to one or more servers. On connect, the client discovers each server's tools/resources/prompts, then routes the model's calls to the right server.

4 · Advanced — capability discovery advanced

Imagine plugging in a new keyboard and having to first tell your operating system every key it has. Absurd — the device announces itself, and the OS just knows. That self-describing handshake is exactly what MCP does with tools, and it's the property that separates MCP from the hand-wired world of Ch 4. There, you hard-coded which tools existed and where they lived. With MCP, the client asks and the servers answer. That question-and-answer is called capability discovery, and it's the reason the protocol can grow without anyone editing the app.

Concretely: when a client connects to a server, it sends a "list your capabilities" request, and the server replies with its tools, resources, and prompts — each with a name and a machine-readable schema describing its arguments. The client does this for every server it's connected to, then merges the answers into a single combined menu. The most useful shape that merge produces is a map from each tool's name to the server that owns it — a routing table. When the model later says "call create_ticket," the client looks up create_ticket in that table, sees it belongs to the tickets server, and sends the call there. No branching logic hard-coded per tool; just a dictionary lookup.

This is precisely why the lesson calls MCP composable. "Composable" means you can add new pieces and the whole simply grows to include them, with no rewiring. Connect a fourth server and its tools automatically appear in the merged menu — the model can use them on the next turn without a single line of app code changing. That's the payoff of discovery: capability becomes data the client gathers at runtime, not code the developer commits ahead of time.

One honest wrinkle to keep in the back of your mind, because the lab that follows will expose it: merging by tool name assumes names are unique. If two servers both advertise a tool called search, a naïve merge silently lets one clobber the other, and calls misroute. Real MCP clients guard against this — typically by namespacing tools per server (so you get github.search and jira.search rather than a bare search) or by an explicit precedence rule. The point isn't the exact fix; it's that discovery is a merge, and every merge has to decide what happens on a collision. Watch for that as you read the code — it's the difference between a toy example and a router you'd trust in production.

Discovery is what makes MCP composable: a client asks each server "what can you do?" and merges the capabilities. Model it.

discovery.pydef discover(servers):
    """servers: {name: {tools:[...], resources:[...]}}. Merge into one capability map."""
    tools, resources = {}, {}
    for name, cap in servers.items():
        for t in cap.get("tools", []): tools[t] = name        # tool -> which server
        for r in cap.get("resources", []): resources[r] = name
    return tools, resources

servers = {
    "docs":    {"tools": ["search_docs"], "resources": ["kb"]},
    "tickets": {"tools": ["create_ticket", "lookup_ticket"], "resources": ["queue"]},
}
tools, res = discover(servers)
print("available tools:", tools)
print("create_ticket lives on:", tools["create_ticket"])

available tools: {'search_docs': 'docs', 'create_ticket': 'tickets', 'lookup_ticket': 'tickets'}
create_ticket lives on: tickets

5 · Professional — the growing ecosystem professional

The N+M math has a consequence people miss on first read: that "M" doesn't all have to be built by you. Every server anyone else publishes is one you don't have to write. This is where MCP stops being a clever protocol and starts being a leverage multiplier — because it's open, other teams and companies have already wrapped the common systems as servers, and their work drops straight into your stack.

The analogy is package managers. Before pip or npm, you wrote (or copied) every utility yourself; after them, you install a battle-tested library and move on to your actual problem. An open MCP ecosystem does the same thing for AI integrations. Need your agent to touch the filesystem, query Postgres, read GitHub issues, or post to Slack? Rather than building and maintaining that connector — auth, error handling, schema, the lot — you connect an existing community server that already speaks MCP. Your team's scarce time goes to the integrations that are genuinely yours, the ones no one else can build because they wrap your proprietary systems.

Read this section as the shift from author to assembler. At the professional level the interesting decision is no longer "how do I write a connector" but "which of these do I build versus reuse." Anything already in the ecosystem is an N+M reuse — plug it in. Anything unique to your organization is a server you expose once, and from that moment every AI tool in your company can use it without a second integration. The mistake at this stage is reflexively rebuilding what already exists (a filesystem server, say) out of habit or mistrust; the discipline is to reuse aggressively and reserve your engineering for the systems only you have. That reuse-versus-build judgment is what the tech-lead section turns into an actual org strategy.

MCP is open, so an ecosystem of servers exists for common systems (filesystems, databases, GitHub, Slack, etc.). Adopting it means reusing community servers and exposing your own systems once for every AI tool your org uses — rather than rebuilding integrations per app.

6 · Tech-lead — an org MCP strategy tech-lead

Here's the failure mode that turns MCP from an asset into a liability, and it happens fast. The protocol makes connecting a server so easy that, left ungoverned, every engineer wires up whatever they find. Six months later you have forty ad-hoc connections, three teams that each built the same "internal-docs" server, an unvetted community server someone pointed at production, and zero record of which AI app touched which system when. The very ease that made MCP attractive has recreated the sprawl — this time with a security surface attached. A tech lead's job is to get the N+M leverage without that chaos.

The answer is to treat MCP servers the way a mature org treats any shared infrastructure: as a curated, governed catalog rather than a free-for-all. Concretely, a lead decides four things. First, what to expose — which internal systems become servers, built once and shared, so no team rebuilds them. Second, what to trust — which community servers are vetted and approved, because an MCP server is code you're granting tool access to, and a malicious or sloppy one is a real threat (that vetting connects to the safety work in C4). Third, discoverability — a registry so teams can find the approved servers instead of reinventing them. Fourth, governance — who may call which tools, and an audit trail of every call.

The cleanest way to enforce all four at once is a gateway: a single chokepoint that every client connects through, which registers the approved servers, checks a per-client allowlist before routing a call, and logs the outcome. That one pattern gives you the N+M wiring plus centralized authentication, least-privilege access, collision checks, and audit — the difference between "we use MCP" and "we operate MCP safely." The strategic mistake to avoid is treating high-blast-radius tools (a run_sql against production, say) as ordinary capabilities granted by default; in a governed setup those are granted narrowly, to the few clients that genuinely need them, and denied-by-default to everyone else. The table below contrasts the ungoverned world with the governed one — read it as the before-and-after of applying exactly this thinking.

A lead decides the org's MCP posture: which internal systems to expose as servers, which community servers to trust (vetting them — C4), a registry so teams discover them, and governance (access, audit). This turns scattered integrations into shared, governed infrastructure.

def integrations(n_clients, m_tools, with_protocol):
    if with_protocol:
        return n_clients + m_tools     # each side wires to the standard once
    return n_clients * m_tools         # every app -> every tool

n, m = 5, 8
print(integrations(n, m, False))       # 40  (N x M explosion)
print(integrations(n, m, True))        # 13  (N + M)
print("saved:", integrations(n, m, False) - integrations(n, m, True))  # 27

def discover(servers):
    """servers: {name: {tools:[...], resources:[...]}}. Merge into one map."""
    tools, resources = {}, {}
    for name, cap in servers.items():
        for t in cap.get("tools", []):     tools[t] = name
        for r in cap.get("resources", []): resources[r] = name
    return tools, resources

servers = {
    "docs":    {"tools": ["search_docs"],                 "resources": ["kb"]},
    "tickets": {"tools": ["create_ticket", "lookup_ticket"], "resources": ["queue"]},
}
tools, resources = discover(servers)
print(tools)      # {'search_docs':'docs','create_ticket':'tickets','lookup_ticket':'tickets'}
print(resources)  # {'kb':'docs','queue':'tickets'}

def discover(servers):
    tools, collisions = {}, {}
    for name, cap in servers.items():
        for t in cap.get("tools", []):
            if t in tools:                       # two servers export same name
                collisions.setdefault(t, [tools[t]]).append(name)
            else:
                tools[t] = name
    return tools, collisions

def route(tools, name):
    if name not in tools:
        raise KeyError(f"no server exports tool {name!r}")
    return tools[name]

servers = {
    "gh":    {"tools": ["search", "create_issue"]},
    "jira":  {"tools": ["search", "create_ticket"]},   # 'search' collides
}
tools, collisions = discover(servers)
print(route(tools, "create_issue"))   # gh
print("collisions:", collisions)      # {'search': ['gh', 'jira']}

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("calc")          # server name shown to clients on discovery

@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two integers."""    # docstring + type hints become the tool schema
    return a + b

if __name__ == "__main__":
    mcp.run(transport="stdio") # stdio is the standard local transport

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

async def main():
    params = StdioServerParameters(command="python", args=["calc_server.py"])
    async with stdio_client(params) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()
            tools = await session.list_tools()          # discovery
            print([t.name for t in tools.tools])        # ['add']
            result = await session.call_tool("add", {"a": 2, "b": 3})
            print(result.content[0].text)               # '5'

asyncio.run(main())

class MCPGateway:
    def __init__(self):
        self.registry = {}       # tool_name -> server_name
        self.allow = {}          # client -> set(tool_name)
        self.audit = []

    def register(self, server, tools):
        for t in tools:
            if t in self.registry:
                raise ValueError(f"tool name collision: {t}")
            self.registry[t] = server

    def grant(self, client, tools):
        self.allow[client] = set(tools)

    def call(self, client, tool, args):
        if tool not in self.registry:
            raise KeyError(f"unknown tool {tool!r}")
        if tool not in self.allow.get(client, set()):     # least privilege
            self.audit.append((client, tool, "DENIED"))
            raise PermissionError(f"{client} may not call {tool}")
        self.audit.append((client, tool, "OK"))
        return f"routed {tool} -> {self.registry[tool]}({args})"

gw = MCPGateway()
gw.register("tickets", ["create_ticket"])
gw.register("prod-db", ["run_sql"])
gw.grant("support-bot", ["create_ticket"])   # NOT run_sql
print(gw.call("support-bot", "create_ticket", {"title": "reset"}))
try:
    gw.call("support-bot", "run_sql", {"q": "DROP TABLE users"})
except PermissionError as e:
    print("blocked:", e)
print("audit:", gw.audit)

Knowledge check check yourself