The integration bill nobody itemises

Four systems, three assistants, twelve integrations

Atrium Works is a co-working floor with three bookable rooms and a front desk that runs on four systems: a booking database, a Slack workspace, a Stripe account, and a shared calendar. The floor manager wants an assistant that can answer "is Studio B free on Thursday afternoon?" without her opening anything.

So somebody writes the integration. The assistant needs to read the booking database, so a developer writes a function that queries it, describes its arguments in whatever shape that assistant expects, handles its errors, and ships it. Then the same for the calendar. Then Slack. Then Stripe. Four integrations, and the assistant works.

Six months later the company adopts a second assistant — a coding agent that lives in the editor, which would be genuinely useful for the internal tooling. It cannot use any of the four integrations that already exist. They were written against the first assistant's function-calling format, its error conventions, its authentication story. So somebody writes them again. Four more.

Then a third surface appears, because the floor manager wants the same answers in a chat widget on the members' portal. Four more.

Three assistants, four systems, and the arithmetic is not three plus four:

3 assistants x 4 systems = 12 integrations to write and maintain

Twelve pieces of code that do four things. When Stripe changes an API, three of them break. When a developer improves the error handling in one, the other two keep the old behaviour until somebody remembers. Nobody planned this; it is what happens when the interface between an AI application and a system is invented fresh each time.

The drawer

Everybody who has owned electronics for a decade has a drawer with eleven dead chargers in it. Not because anyone chose to accumulate them, but because for years every device shipped its own barrel jack, and the only way to charge a thing was the cable that came with it. The drawer is not a design; it is the residue of an absent standard. The twelve integrations above are the same drawer, and the same cause.

The fix in both cases has the same shape. Agree on one interface. Let the device expose it once and the charger provide it once, and the number of cables you need stops being a product and starts being a sum.

What M+N actually buys you

The Model Context Protocol is that agreement for AI applications. A system exposes its capabilities once, as an MCP server. An AI application speaks the protocol once, as an MCP client. Neither knows anything specific about the other.

Redo the arithmetic under that rule. Four systems each expose one server. Three assistants each speak the protocol. Nothing is written per pair:

3 assistants + 4 systems = 7 pieces, and none of them are per-pair

Twelve becomes seven, but the count understates it. The real change is what happens next year. Adding a fourth assistant used to cost four new integrations; now it costs zero, because every server it needs already exists and already speaks the protocol it speaks. Adding a fifth system used to cost three; now it costs one. The cost of a new participant stopped scaling with how many other participants there are, and that is the whole point.

It also changes who can do the work. The team that owns the booking database is the team that should describe how to query it — they know which fields are stale, which query is expensive, and what "free" means on a day the floor closes early. Under the old arrangement that knowledge had to be re-transmitted to whoever was writing each assistant's integration. Under MCP they write one server, and every assistant inherits their judgment.

What this course teaches, and when it disagrees with the internet

This course teaches spec version 2026-07-28 and Python SDK v2. Both changed substantially during 2026, and most MCP material published before then describes the previous design. Where this course and an older tutorial disagree, the disagreement is real, and Lesson 5 explains every one of them. You will not have to guess which of us is out of date.

You will build one server across the whole course: atrium-mcp, the server behind Atrium Works. It runs on a dict and a SQLite file, so there is no API key to obtain and no cloud account to open. By the end it will find slots, take bookings, cancel them, ask the user a question when a request is ambiguous, run a job that takes minutes without holding a connection open, and answer with a rendered grid instead of a sentence.

And the question it exists to answer is one sentence, which you should hold on to now, because the whole course is scaffolding for it.

Book the big room for Thursday

That is a request the front desk answers in one glance and a machine cannot answer at all.

The big room — The Atrium has 24 seats, which makes it the biggest room on the floor. But the design team on the second floor have called Studio B "the big room" for two years, because it is the biggest room upstairs and they never come down. Which one is meant depends on who is asking.

Thursday — tomorrow, if today is Wednesday. Next Thursday, if today is Thursday, or possibly today. The word does not carry the answer.

For how long? — unstated. An hour is the usual booking, but the reason people book The Atrium is the all-day workshops.

A person resolves all three without noticing they were ambiguous. A machine that guesses gets one of them wrong roughly a third of the time, and a booking system that is wrong a third of the time is worse than no booking system, because now somebody has to check it.

Most of what makes MCP more than a remote function call is machinery for handling exactly this: describing a capability well enough that a model picks the right one, and asking a human when description is not enough. We will answer this sentence in code in Lesson 23.

What to take into the next lesson

Integration cost without a standard is a product, M x N, and every participant you add multiplies it. MCP makes it a sum by putting one agreed interface between the two sides, so a system describes itself once and every application understands it. That is the entire economic argument, and everything else in this course is the mechanics of making the description good enough to act on. Next: what MCP actually is, which is not what most people assume when they first pip install it.