MCP Chaining Across Design Tools

Module 2 ended with patterns — fan-out, pipelines, critic pairs — described in terms of agents and briefs. This module supplies the plumbing those patterns run on when the work spans tools: the research board, the design canvas, the repository, and the browser, all reachable from one agent session over MCP. The framing to establish up front is that a chain is not a fancier connection; it is a workflow design decision. Which tool is the source of truth for which fact, what may be written where, and what happens when a link is down are design questions, not configuration trivia.

Set expectations on prerequisites. The module assumes participants already know what MCP is and have connected at least one server — that material is covered in the school's MCP for Designers article and in the foundations course. What it does not assume is any experience running multiple servers in one session, which is genuinely different in its failure modes and its cost profile.

Also flag the honesty posture for the module: the worked example later draws on this school's own sync experiments, including a remote write path that is currently blocked at the authentication boundary. The point of including the failure is that it is the most common real outcome, and designing for it is most of the skill.

Anchor the distinction in jobs rather than architecture. A single design-server connection answers questions about one tool: what variables does this frame use, what does this board say. The workflows that justify this module need two sources at once: token sync compares design-tool variables against the repository's CSS custom properties; content sync reads real research from a board and pushes it into mockups; an implementation review reads intent from the design server and reality from the browser server and reports the difference. None of those is possible with one connection, and all of them collapse back into manual copy-paste without MCP.

The mechanism is mundane and worth saying plainly: multiple MCP servers can be active in the same agent session, the agent picks tools across all of them, and every result lands in the same context window. There is no special chaining feature — the chain is just the order of tool calls the agent makes, steered by your prompt and harness.

Name the costs in the same breath, because the rest of the module is about managing them. Each connected server adds tool definitions to every request, each remote server adds a credential to manage, and screenshot-heavy chains burn context quickly. The honest default is to connect what the task needs, not everything the project owns.

The table groups servers by the role they play in a chain rather than by vendor, because that is the decision a chain designer actually makes: where does intent come from, where does content come from, where does evidence come from, and where does the artifact live. Most real chains use one server per role, not every server you have.

A few date-stamped specifics worth voicing. Figma's official MCP server is in beta as of June 2026, comes in remote and desktop forms, reads design context, variables and screenshots, and can also write to the canvas — rate limits vary by seat type, so check before building a daily ritual on it. Pencil and Paper are the connected-canvas pair: local servers, no auth, and the canvas file itself is diffable. Playwright and Chrome DevTools are official Microsoft and Google servers respectively, and they are the half of the chain designers most often forget — without them the chain produces work but no evidence. Ticketing servers matter mostly for orchestrated team workflows, where the chain's output needs to land where the team already tracks work.

The last row is the quiet point: the repository participates in every chain through ordinary file tools, no MCP required, and it is where writes are safest because they arrive as reviewable, revertible diffs. When in doubt about where a chain should write, the answer is usually the repo.

The discipline here mirrors the worker-prompt discipline from Module 2: define the boundary before the work starts. For a chain, the boundary questions are which server feeds which step, in which direction, and which system is the source of truth for each kind of fact. Tokens might be owned by the repository with the canvas as a renderer of them, or owned by Figma variables with the repo following — both are workable, but a chain where both sides think they own the tokens will quietly overwrite one of them.

The read/write marking matters because it determines the permission posture and the blast radius. Most links in a healthy chain are reads: read the board, read the variables, read the screenshot. Writes should be few, late in the chain, and ideally aimed at reviewable surfaces — a branch in the repo, a clearly named page in the canvas — rather than at shared live boards.

The last bullet connects this module back to the harness material from the foundations course. A chain that lives only in one person's prompt history is a demo. A chain documented in the project's instruction file — which servers, which order, which tools are pre-approved, where the gates are — is a workflow the whole team and every future session inherits.

Walk the diagram left to right as a typical chain run. The research board is read-only by policy: it feeds the brief and supplies real content, and there is rarely a good reason for an automated chain to write back to a shared live board. The design canvas is the intent source — variables, structure, reference screenshots — and increasingly a write target too, but writes there belong behind a permission prompt and aimed at a clearly named page. The repository participates through ordinary file tools and is where the artifact actually lives; its writes are branches and diffs, which is what makes them safe. The browser closes the loop: screenshots and console output as evidence for review, never writes.

Then spend equal time on the bottom band, because it is the part people skip until it bites. Remote servers fail at the credential boundary — OAuth registration rejected, enterprise policy blocking the connector — often before a single tool is listed. Local servers fail because the app behind them is not running: the design editor, the desktop app, the dev server. Long sessions go stale and tool calls start hanging. And context burn is the silent one: tool definitions for every connected server ride along with every request, screenshots are large, and a chain can spend its reasoning budget on plumbing.

The design lesson is that none of these is exotic. They are operational facts you can plan for: check connections at the start of a run, keep sessions lean, and have a fallback for the link most likely to be blocked.

The principle is least access that still works, applied at three layers. The first is which servers are connected at all: project scope rather than global, in a checked-in file the team can review, so a client project never silently inherits servers from another. The second is whose credentials the OAuth grant or token belongs to: an account with access to this project's files, not an admin account with the whole organisation's workspace behind it. The third is which tools are pre-approved versus prompted: read tools can be allowed once a server is trusted, write tools stay on ask.

The code excerpt shows the Claude Code shape — a checked-in settings file naming which servers are enabled and which specific tools are allowed without prompting — but the same posture exists on the other platforms: Gemini CLI has an allowlist for which servers may connect, OpenCode keeps enabled flags in a reviewable JSON file, and Codex CLI's config.toml should be reviewed like any other dotfile change. The portable idea is that the permission posture is itself a reviewable artifact, not a per-person preference.

There is also a prompt-injection angle worth one sentence: everything a server returns — sticky-note text, layer names, page content — enters the agent's context as untrusted input, and the reason writes stay behind prompts is so an instruction smuggled in through a board cannot quietly become a canvas edit or a file write.

This is the slide where the orchestration view and the governance view meet. A chain is, by definition, a machine for moving information between systems — that is its value, and it is also the risk. The questions to settle per chain: what can each connected server see, which links are remote (meaning data leaves your machine and transits a vendor's infrastructure), and which moves between systems are actually permitted by your client agreements, your research consent, and your own policies.

Give concrete examples rather than abstract policy. Research boards often contain participant quotes and personally identifying detail collected under a consent form that did not mention pushing them into a Figma file shared with a vendor. Unreleased product designs flowing out through a remote server may be fine for an internal project and a contractual problem for a client engagement. And in agency or multi-client settings, the strongest boundary is structural: per-project server config and per-project credentials mean the chain physically cannot reach the other client's files, which beats relying on the agent to remember a rule.

The practical move is to write the allowed flows into the harness in plain language — what may leave the research board, where canvas content may go, what must never appear in tickets — so the boundary survives staff changes and session restarts. Keep the claims conservative: this is a fast-moving area, and as of June 2026 most teams are still working these policies out as they go.

The learning objective behind this slide is the phrase fail loudly and partially rather than silently and completely. The worst chain outcome is not a crash — it is a polished-looking deliverable assembled around a link that quietly failed: a token sync report that never actually read the design variables, a review that compared the page against a stale screenshot, a canvas update that wrote half its frames and stopped. Agents are good at producing plausible output, and plausible output over a hole is exactly what slips through review.

Walk the table by failure class. Credential failures on remote servers are the most common first-run failure and usually need a human or an admin; the useful behaviours are reporting the exact error and falling back to a local path where one exists — a plugin, a file import, a CLI. Apps not running are trivially fixable but only by a human, so the chain should stop and say so rather than guess. Stale connections deserve one retry, not an improvised workaround. Partial reads are fine if the gap is labelled. And failed writes are the hard rule: nothing downstream of an unconfirmed write should run, because cleaning up a half-applied change across two systems is far worse than rerunning a chain.

Most of this is implemented in prompts and harness instructions rather than code: tell the agent explicitly to verify each connection before relying on it, to report failures verbatim, and to stop rather than improvise when a write does not confirm.

Observability sounds like an engineering luxury until the first time someone asks what changed on the shared canvas last Tuesday and nobody can answer. For design chains the bar is modest and reachable: you should be able to reconstruct, after the fact, which servers the session used, what it read, what it wrote and where, and which steps failed or were skipped. Most agent platforms show the tool-call trail in the session; the discipline is keeping it — in the run log, the pull request description, or a status file — rather than letting it evaporate when the terminal closes.

The dated status record is a pattern worth stealing from this school's own sync pipeline: every run writes a small JSON file recording what was rebuilt, what was pushed, and which path failed with which error. When the remote write path was blocked at OAuth, the status file said so honestly, and the next attempt started from evidence instead of memory. The same idea scales down to a paragraph at the end of a chain prompt: list what you read, what you wrote, and what you could not do.

The context-spend bullet is observability of a different kind: a chain that is degrading because its context is full of screenshots does not announce itself. Keeping review sessions separate from build sessions, requesting specific frames rather than whole pages, and disconnecting unused servers are the boring fixes. This connects forward to Module 6, where cost and audit trails get treated as team-level operations rather than personal habits.

Walk the chain as a story rather than a feature list. The task shape is one this course keeps returning to: take a researched piece of content or a design decision, get it built in the product's real materials, and verify the result against the design source. Step one reads the research board for the findings and the real content — read-only, and gated by a human confirming scope, because this is the point where the brief is still cheap to change. Step two reads the design canvas: variables, structure, and a reference screenshot, which together form the design contract. Step three is the build, and it deliberately writes to the repository on a branch rather than to any live surface. Step four turns the browser server on the result: screenshots at a desktop and a mobile width plus console output, compared against the contract from step two and reported as P0 to P3 findings. Step five writes the status record.

Be honest about effort and failure rates, drawing on the school's MCP article: assembled from documented tool surfaces, a chain like this is roughly eight to twelve tool calls plus the comparison and write-up, and in practice the first attempt rarely survives without one connection or wrong-node retry — typically a design editor or dev server that was not running. That is a few minutes of agent time for a review a designer would spend half an hour doing less systematically by tab-switching.

Point out what makes the chain safe rather than just fast: every write lands on a reviewable surface, the only irreversible-looking step (the canvas) is read-only here, and the gates sit exactly where the failure handling slide said they should — before the first write and after the evidence comes back.

These findings come from the school's two published field notes on syncing its design system outward: one to OpenPencil, one to Figma over MCP. The OpenPencil note shows the happy half: a watch loop rebuilds a file-backed canvas — token boards, component boards, key screens — from the same files the site is built from, so the canvas became a build output rather than an artifact anyone maintains by hand. The honest caveat in that note is that the round trip is not closed: the HTTP MCP bridge to the desktop app was not reliably connected, so the chain runs one way, code to canvas.

The Figma note is the more instructive failure. The same generated payload was pointed at Figma's remote MCP server, and the standalone client was rejected during OAuth client registration with an HTTP 403 before any tool was listed. Nothing in the payload or the script was at fault — the failure sat exactly at the authentication boundary, which is where most agent-writes-to-vendor-SaaS workflows currently break. The chain still shipped because two fallbacks existed: the Figma MCP tools registered through another agent platform authenticated fine for inspection and targeted writes, and a local development plugin handled full canvas refreshes without any remote endpoint.

The transferable lessons are the two on the slide: treat the credential boundary as the link most likely to fail, and keep a boring local fallback for it; and record every failure in a dated status file. Both are cheap, and both are exactly what the failure-handling and observability slides asked for — this is what they look like in practice.

The exercise is deliberately a paper exercise, like the one in Module 2: the design of the chain is the skill, and connecting servers is the easy part once the design exists. Steer participants towards a workflow they already do manually — comparing design variables to the repo's tokens, reviewing a built page against its design source, refreshing mockups with real content — rather than inventing a new workflow to justify the tooling.

The checks built into the bullets mirror the module: roles and direction per link, a single source of truth per fact, a permission posture that could be checked into the repo, explicit data boundaries, and one line of failure handling per link including the fallback for whichever link is most likely to be blocked — usually the remote one with OAuth in front of it.

If running this live, have people swap pages and review each other's chains against two questions: where would this chain fail silently, and what would you not be able to reconstruct afterwards? Those two questions catch most of the weak designs, and they are the same questions Module 6 will ask at the level of the whole team's operations. Keep the page; the concurrent-canvas module next builds on the same workflow.

Recap by tying the slides back to the three learning objectives. Designing a chain where each connection has a defined role and scope was the server map, the chain-design slide, and the diagram. Handling credentials, permissions, and data boundaries was the least-access posture and the data-boundaries slide. Building chains that fail loudly and partially was the failure-handling table, the observability slide, and the field evidence — the OAuth 403 and the one-way canvas sync are what those principles look like when they meet a real vendor boundary.

Remind people of the date-stamps. The server landscape, Figma's beta status and rate limits, and the exact configuration shapes were verified against documentation in mid-2026 and will drift; the chain-design discipline, the permission posture, and the failure-handling rules are the parts that will still be true when the tool names change.

Then set up Module 4. This module had one agent operating several tools. The next one inverts it: several agents operating one shared surface — a canvas or design file — at the same time, which raises a different set of problems: zone ownership, naming and component conventions agents can actually follow, conflict cases around shared tokens and components, and the review rhythm that catches divergence before it spreads. The chain map from the exercise carries forward, because a shared canvas is usually one link in a larger chain.