An MCP server that answers one tool call on your laptop has proved little. A production server must expose outcomes an agent can select, work across uneven clients and keep working after it moves behind a remote URL. Tools, resources and prompts establish the divisions before an API is cut down to an agent-facing interface. Figma provides the field test: React and Tailwind proved more usable to models than a private scene-graph format. Images help until base64 floods the context, and Code Connect matters more than pixel-perfect markup. Remote transport, OAuth, private registries and durable tasks follow because that server now has to operate. The last two talks place MCP beside skills and CLIs, then trace a call across the client-server boundary, where production failures are otherwise easy to miss.
Why first: Chu starts before the server code. MCP came from engineers repeatedly copying Slack messages and Sentry logs into prompts, then asking for one open way to connect models to outside context and actions. Her account also explains a choice that shapes Murag's architecture: when one side must carry complexity, MCP favors simpler servers and more capable clients.
Why second: Chu gives the origin and the trade-offs. Murag names the actual pieces: model-controlled tools, application-controlled resources and user-controlled prompts. He also draws the line Lowin needs for the next talk. MCP brings context into an agent; the framework still runs the loop and decides what to do with the result.
Why here: Murag shows what a server can expose. Lowin asks what an agent can afford to discover and use. His answer is severe but useful: hide known API sequences behind one outcome, flatten the arguments, write errors that help the model recover, and cut tools until the server fits inside the agent's context. Kirschner tackles the same pressure from the client side next.
Why here: Lowin curates a fixed server interface. Kirschner shows a client and server changing that interface with the user's state, so a battle tool appears only when a monster does. Resources, roots, sampling and server debugging fill out the protocol he thinks most clients underuse. Figma then shows what builders do when that full client support exists only on paper.
Why here: Kirschner describes the client he wants. Lumarie shipped against the clients he had. Figma replaced unsupported elicitation and sampling flows with tool calls, kept images out of base64-heavy context, and launched locally while remote authentication was still unsettled. Once the remote server arrives, Welsh's transport and gateway decisions stop being abstract infrastructure.
Why here: Figma reaches remote deployment by working around an immature ecosystem. Welsh makes remote MCP routine inside Anthropic. He separates the JSON-RPC messages from the stream carrying them, then puts routing, credentials, rate limits and observability behind one gateway. Delimarsky and Kasper open up one part that gateway conceals: the OAuth exchange.
Why here: Welsh says the gateway handles authentication once for every service. Delimarsky and Kasper trace the exact flow: a server returns a 401 with protected resource metadata, the client discovers the authorization server and gets a token, and the MCP server validates it. With one remote server protected, Merla, Luchetti and Redaelli ask how a company publishes and governs dozens of them.
Why here: Delimarsky and Kasper protect one remote server. Merla, Luchetti and Redaelli place many of them in Amplifon's private registry, adding owners, environments, authentication requirements, cost attribution and linked use cases. Their CI pipeline publishes the Docker image and registry metadata together. Davis follows that deployed call past the point where a normal request would have timed out.
Why here: Amplifon gets a server into production; Davis asks how its work survives there. An asynchronous tool returns a task handle, waits for approval and resumes after clients or servers disappear. Her comparison of the stateful first design with a stateless core makes the protocol's durability cost concrete. Soria Parra then places that richer MCP machinery among the other ways agents connect to systems.
Why here: Davis shows why some work needs more than an immediate tool response. Soria Parra widens the choice: use skills for knowledge, command-line or computer access where the environment supports it, and MCP for rich semantics, authorization and tasks. Within MCP, load tools only when needed and compose calls in code. More connections make the blind spot in the last talk larger.
Why last: Soria Parra gives an agent several ways to reach outside systems. Volkov and Eckel show what operators lose when those calls cross a process or company boundary. OpenTelemetry can join client and owned-server spans when trace context crosses MCP, but a third-party server remains a black box. The protocol is useful only in production if a failed run leaves enough evidence to inspect.