Part 1 Capstone: Scenario Picks + Closing Exercise

Duration
30 min
Last verified
2026-06-12
Source outline section
Part 1 capstone (Module 1.4 exit)
Exit criterion
You have applied the Module 1.4 decision framework to three concrete scenarios, defended each choice with the framework's terms, and completed the migrate-to-runsnative exercise.

Part 1 ends with two things: a decision exercise and a lab. The decision exercise tests whether the transport-binding framing from Module 1.4 is actually operative — whether you can use it on scenarios you haven’t seen before, not just explain it back. The closing lab demonstrates what well-designed tools enable when a consumer uses them as intended.

The scenario exercise

Three integration scenarios follow. For each one, read it and decide: local MCP, remote MCP, or plain API? Work through the decision before reading the answer discussion. The answer is not always obvious, and the answer discussion names which principle drives the call. Use your notes from Module 1.4’s decision tree.

Scenario A — The shared design-system query server

A design-system team maintains a component library. They want developers using Claude Desktop, Cursor, and other MCP-capable editors to be able to query the library from their agent sessions — asking questions like “which component handles paginated data display?” or “show me the accessibility notes for the modal dialog.” The team does not control which editor any given developer uses. The library content lives in a cloud API the team operates.

Your pick: local MCP / remote MCP / plain API?

Answer discussion (read after you have made your pick)

Remote MCP. The consumer surface is multiple agent hosts the team does not control — exactly the condition under which MCP earns its place. The N×M leverage is real: one conforming server implementation reaches Claude Desktop, Cursor, and any future MCP-capable editor in the ecosystem. The content lives in a cloud API the team operates, so remote transport is natural — the server is already a networked service. Module 1.3’s OAuth flow is required because the server is remote, but the design-system team presumably already operates auth for their cloud API.

Why not local stdio? The server would need to be installed per developer machine, and the content API is remote anyway — there is no filesystem or process access the local process model provides. The deployment lifecycle (update the cloud content; zero client-side action required) argues for remote.

Why not plain API? The team does not control the consumers. A plain HTTP API would require each editor team to write a custom integration. MCP buys the single-implementation/multi-host leverage that makes the difference.

Scenario B — An internal CI pipeline that calls an LLM to classify failing tests

A platform team has a CI pipeline that runs tests. When tests fail, an automated step calls an LLM via the Anthropic API to classify the failure type (configuration error, flaky test, genuine regression). The LLM call is already working as a plain HTTP POST in the pipeline’s Python script. A new team member suggests wrapping this in an MCP server so “the agent can call it.”

Your pick: keep it as a plain HTTP call / wrap it in a local MCP server / wrap it in a remote MCP server?

Answer discussion (read after you have made your pick)

Keep it as a plain HTTP call. The CI pipeline is the sole consumer of this capability, and the pipeline team controls both the capability (the LLM classifier) and the consumer (the pipeline script). There is no N×M problem to solve. Wrapping it in an MCP server would add a protocol layer, a client library dependency, and a running process to maintain — all for zero leverage, because the consumer is not a third-party agent host and cannot use the MCP client integration anyway.

The suggestion “so the agent can call it” contains a hidden assumption: that the agent is an interactive agent host like Claude Desktop, which would benefit from the MCP integration. But a Python script in a CI pipeline is not an MCP client. If the pipeline were replaced by a Claude Code session that an engineer drives interactively, and the classifier became a tool that engineers wanted available in their agent sessions, the calculus would shift toward local MCP. The scenario as stated does not support that shift.

The one-new-primitive principle applies here: the LLM classification call is the nondeterministic API; the wrapper is standard infrastructure. Don’t add the infrastructure without a reason.

Scenario C — A proprietary customer-data tool for a SaaS product

A SaaS company wants to give its customers the ability to query their own account data from any MCP-capable agent they use. Customers use a mix of Claude Desktop, Claude Code, and Cursor. The data lives in the company’s database, scoped per customer. Each customer’s agent session should see only their own data.

Your pick: local MCP / remote MCP / plain API?

Answer discussion (read after you have made your pick)

Remote MCP. This is the cleanest case for remote MCP: the consumers are multiple hosts the company does not control; the data is customer-scoped and lives in the company’s infrastructure (not on the customer’s machine); centrally-managed auth is required for data isolation.

The multi-tenancy and per-customer data scoping make remote transport necessary — a local stdio server would run with the customer’s machine credentials and could not enforce server-side scoping against the company’s database. A remote server with OAuth 2.1 (Module 1.3’s flow) lets the company issue per-customer tokens that scope data access correctly.

The N×M leverage is real: one server serves Claude Desktop customers, Cursor customers, and future MCP-capable hosts without additional integration work per host.

Why not plain API? Same answer as Scenario A: the company does not control the consumers. A plain HTTP API would require each editor team to write a custom connector. The API might be the right internal choice for service-to-service calls within the company’s infrastructure — but for the customer-facing agent integration, MCP buys the single-implementation leverage.

The closing exercise: migrate-to-runsnative

The decision exercise tested the framework. The closing exercise tests what well-designed tools enable when you use them end-to-end as a consumer.

In your agent session, ask your agent to call start_exercise with the name migrate-to-runsnative. The exercise runs for approximately 15 minutes. It is a guided, step-gated migration flow: convert an existing HTML prototype to RunsNative components in four passes — theme inference, primitive identification, compound recognition, and generate.

The exercise demonstrates exactly what Module 1.1 described in the abstract: a server whose tools have precise descriptions and typed schemas produces an agent that reaches for them correctly without being told. You are the consumer; the server is the capability provider; the agent is the integration. No code is written on your side. The server does the work; the tools are the interface.

You know it worked when: you reach the end of the exercise’s step list and the agent has completed the migration. If the agent gets stuck or misuses a tool, that is worth noting — it is almost always a description or schema issue on the server side, not an agent issue. Part 2’s Module 2.2 turns that observation into a design discipline.

What Part 1 delivered

Before you proceed to Part 2 (if you are going further), take stock. At the end of Part 1 you can:

Part 1 is the generic, industry-portable layer: everything in it applies regardless of which MCP server you work with and which host you use. Part 2 climbs the layer diagram — it dissects the artifact, teaches tool design, introduces the Mukadra agent gateway framework, and ends with authoring a server of your own.