MCP Integrations and Team Workflows

This is the closing module of the course, and it deliberately changes scale twice. The first half scales the agent's reach: instead of feeding Claude Code screenshots and pasted hex values, MCP lets it read your design tools directly and act on the live page. The second half scales the practice from one enthusiastic designer to a team that gets repeatable results without everyone reinventing the setup.

Set expectations honestly. MCP setup is configuration work, and the team material is process work — neither is glamorous, and both are exactly the kind of thing that decides whether the techniques from Modules 3 to 6 survive contact with a real team. Participants who have only ever run Claude Code solo tend to underestimate how much of their personal setup lives in their head; this module is about getting it into files the team can share.

If the audience includes design leads or managers, flag that the second half — shared harness files, conventions, cost, rollout — is written for them. If it is mostly individual contributors, the same content tells them what to ask their lead for.

The framing that lands with designers is the copy-paste tax. Without MCP, every handoff between the design tool and the agent is manual and lossy: exported PNGs with no token names, screenshots of boards, hex values copied one at a time. The agent works from degraded copies of intent and then gets blamed for guessing. MCP removes that tax by letting the agent call the tool directly and get structured data back.

Keep the mechanics simple: a server is a small program that speaks the protocol and exposes a handful of named tools; Claude Code is the client that calls them. Servers can also expose resources and prompts, but for design work nearly all the value is in tools. The local-versus-remote distinction is the one worth internalising because it predicts failures: local servers (Pencil, Paper, Playwright, Chrome DevTools) only respond while the app behind them is running; remote servers (Figma, Miro, Notion) authenticate over OAuth and bring rate limits.

The governance point matters for anyone about to invest team time. Anthropic released MCP in late 2024 and donated it to the Agentic AI Foundation under the Linux Foundation in December 2025; Claude Code, Codex CLI, OpenCode, Gemini CLI, Cursor and others all ship clients. As of June 2026 this is the closest thing the agent ecosystem has to a neutral standard, which makes it a reasonably safe place to build team workflow on.

Walk the table as three groups rather than six rows. Group one is the design source of truth — Figma's official server if the team designs in Figma, or a connected canvas like Pencil or Paper if the team has moved to design-as-code formats. Group two is the browser — Playwright or Chrome DevTools — which is the half designers overlook and the half that makes implementation review honest, because the agent can capture the real page at real breakpoints instead of trusting its own output. Group three is the words: Notion for briefs and specs, Miro for research walls, plus tickets and analytics where relevant.

Be explicit about freshness. The Figma server is in beta as of June 2026, comes in remote and desktop forms, and its rate limits depend on seat type — tight enough on lighter seats that a single chained review eats a noticeable share of a month's allowance. Tool names and plan gating for the newer servers are still moving, so any team document that references them should carry a date.

The last bullet is the practical discipline: every connected server's tool definitions ride along in every request, and screenshots are token-heavy. Six servers and a dozen full-page captures make the agent measurably worse at reasoning. Connect per project, per task, and disconnect what you are not using.

The configuration itself is the easy part: claude mcp add, or hand-edit .mcp.json, and the /mcp command inside a session shows what is connected, runs OAuth for remote servers, and lists each server's tools. The decision that matters is scope. Local scope is just you in this project; user scope follows you everywhere; project scope writes a plain .mcp.json at the repo root that gets committed. Project scope is the one teams should default to, because it turns your personal setup into something a teammate inherits by cloning the repo and approving once.

The three security questions on the slide are the ones to ask before the first impressive demo, not after the first incident. Provenance: lookalike and name-collision servers exist, so verify the publisher in the official MCP registry. Write surface: the major design servers can now modify canvases, so know which tools mutate before connecting. Credential scope: a Figma or Miro OAuth grant should belong to an account with access to this project's files, not the whole organisation's workspace.

Worth saying out loud: read tools you trust can be pre-approved in checked-in settings; write tools should stay on ask. The small friction of clicking approve is the feature. Module 6's automation material applies here too — never blanket auto-approve a server inside a hook or a scheduled run.

This slide carries the security weight of the module, and the framing that works is the dependency analogy: an MCP server is code that runs with access to your tools, and its output lands directly in the agent's context. Treat it the way a careful engineer treats a dependency — verify the publisher, read what it can do, and limit what it can touch.

The point designers most often miss is the second bullet. Content fetched through a server — text layers in a design file, sticky notes on a board, the visible text of a web page — is untrusted input. Any of it could contain instructions aimed at the agent rather than at human readers. That is prompt injection, and the practical defence is structural: keep writes and other consequential actions behind permission prompts so a smuggled instruction cannot quietly become a file edit, a canvas change, or an outbound request. Anthropic's own security guidance says the same thing: use servers you trust, and review what each tool can do before connecting it.

The levers exist on the platform side. Claude Code's checked-in settings can declare which .mcp.json servers are enabled and which specific tools are allowed without prompting versus always asked about. Putting that posture in a committed file means it gets reviewed when it changes, which is exactly how a team keeps the setup honest as servers and tools evolve.

Walk the diagram by following what flows where. From the Figma server: design context for the selected frame, the variables in use, and a reference screenshot — structured intent, not a flattened export. From the codebase: the existing token files and components, which is what stops the agent rebuilding things the project already has. The session compares the two, plans, and then writes — and both write paths are gated. Code changes land as a diff on a scratch branch; review notes or annotated frames go back to the canvas server only after an approval. The grey card is the point of the whole picture: the designer holds the gates.

Name the three chains this shape supports, because they are the recurring team workflows. Token sync: design-tool variables compared against the repo's tokens, drift reported or fixed. Content sync: real research or content pushed into mockups instead of lorem ipsum. Implementation review: design server for intent, browser server for reality, agent for the structured diff — the Visual QA workflow from earlier in the course, now with the agent able to see both sides.

Two cautions. Context burn is real: screenshots from two or three servers in one session eat the window fast, so request specific frames, capture two breakpoints rather than five, and keep review sessions separate from build sessions. And do not chain a write step directly onto an automated comparison — keep a human between read-and-compare and write-and-fix.

This is where the course's earlier material becomes a team capability. Module 5 built CLAUDE.md as a personal harness; here the same file becomes the team's contract with the agent. The test for what belongs in it is recurrence: any correction a reviewer has made twice — spacing comes from tokens, components reuse the existing primitives, never edit the generated token file by hand — should be encoded once in CLAUDE.md rather than re-explained in every session by whoever happens to remember.

The four files on the slide form a layered setup. CLAUDE.md carries the advisory rules and project knowledge. .mcp.json carries the tool connections at project scope. .claude/settings.json carries the deterministic layer: hooks that always run the formatter or the token audit, and the permission posture for MCP tools. Skills package the repeatable multi-step workflows — build a component from a frame, run the design review — so a junior designer and the design lead invoke the same procedure and get comparable results.

The management point: these files change, and the change process is just code review. When someone improves the harness, the whole team benefits on their next session; when someone proposes a rule that is wrong, review catches it. That feedback loop — corrections flowing into committed files instead of evaporating in chat — is the single biggest difference between a team that gets consistent agent output and a team with one impressive demo per person.

These conventions sound like engineering process, and that is the point: the agent's output enters the same pipeline as everything else the team ships, so it follows the same rules. The branch convention matters most. Working on a scratch branch means every agent change arrives as a reviewable diff, and a bad run costs a deleted branch rather than a revert on main. Pair it with the CI material from Module 6 — the design QA checks run on the pull request whether a human or an agent authored it.

The scratch folder convention is small but prevents a real mess: explorations, generated variants, one-off audits and comparison screenshots accumulate fast, and without an agreed home they leak into the repo or someone's desktop. Agree the path once, gitignore it, and let people empty it without asking.

The last bullet closes the loop from the previous slide. Review comments that recur are signals about the harness, not about the agent. If three pull requests in a row get the same correction about spacing or naming, the correction belongs in CLAUDE.md or in a hook, and the reviewer who spots the pattern should make that change as part of the review. Teams that build this habit see review load fall over weeks; teams that do not keep paying the same review cost forever.

Date-stamp this slide every time it is presented; pricing is the most perishable content in the module. As of June 2026, Claude Code is included with Pro, Max, Team and Enterprise plans, and not with the free tier. The Team plan's two seat types are the useful lever for a design team: most people are fine on standard seats, and the two or three designers running long design-to-code sessions daily are the ones who justify premium seats. Usage limits are described relative to each other rather than as published token counts, and hitting limits mid-task is the most common reason people upgrade.

The row teams forget is the last one. Interactive use is covered by subscriptions, but the automation from Module 6 — CI design reviews, scheduled audits, headless scripts — typically runs against API keys with per-token billing. That is a feature, not a trap: it is meterable, cappable per run with a budget flag, and visible in a dashboard. Keep it as a separate line so a misconfigured nightly job is an alert, not a quarterly surprise.

Governance beyond money: Team and Enterprise plans add SSO, central billing and admin controls, and managed settings let an organisation deploy an approved MCP server list. For most design teams the lighter version is enough — project-scoped configs in the repo, reviewed like code — but it is worth knowing the heavier controls exist before procurement asks.

The failure mode this slide exists to prevent is the mandate: a leader sees a strong demo, announces that the team is now agent-first, and three months later usage is two enthusiasts plus quiet resentment. The alternative is slower and works. Pick a small pilot group and a real project — not a toy — and put the harness files in the repo before the first session, because the pilot is testing the system, not individual prompting talent.

Measure something honest and small. Review rounds per change, elapsed time from brief to reviewable draft, and defects caught at the review gate are all cheap to track and hard to argue with. Avoid vanity metrics like number of agent sessions, which measure activity rather than outcome. The pilot's output is not a presentation; it is the improved CLAUDE.md, the .mcp.json, the skills, and a one-page working agreement — the artifact the exercise at the end of this module has each participant draft.

On expansion, pairing beats training sessions: a new designer's first agent task done alongside a pilot member transfers the habits that never make it into documentation. And be straightforward about uneven adoption. Some excellent designers will not want this workflow, and the rollout has to tolerate that without turning tool choice into a loyalty test. What you can require is that work entering the shared repo meets the same gates, however it was produced.

Present this as a composite trace of the workflow the module has assembled, not a benchmark: the steps and tool surfaces are real, the specific feature is illustrative. The thing to point at is how much of the earlier course material is load-bearing here. The brief and plan-first habit come from Module 3. The component reuse and token discipline come from Module 5. The hooks and CI checks come from Module 6. MCP did not replace any of it — it removed the manual ferrying between tools that used to surround it.

Call out the two human gates explicitly. The plan review catches the missing tablet state before anything is built — the cheapest correction in the whole run. The design lead's review at the end is the same gate any pull request passes, with the addition of the agent's own verification evidence: breakpoint screenshots and the CI design-check results attached to the PR. The lead is reviewing a diff plus evidence, not a promise.

Also note what is not automated. Nobody auto-approved the writes, the merge decision stayed with a person, and the notes written back to the canvas went through a permission prompt. If a participant asks how long this takes, the honest answer is that the agent steps are minutes each, the human gates take as long as careful review takes, and the setup cost — servers, harness, conventions — was paid once, by the team, before this run started.

This exercise produces the document the rollout slide referred to, and it works solo or as a group. Solo participants should write it as a proposal for their team; groups should expect the most useful output to be the arguments, because every section is a decision the team has implicitly been making inconsistently.

Keep the format constraint firm: one page, plain language, no tooling jargon a new designer could not follow on their first day. The five sections map directly onto the module — tools, harness, conventions, gates, cost — and a reasonable first version of each is three or four sentences. Encourage people to name names in the gates section: 'a human reviews it' is a hope, 'the design lead for this project reviews the diff' is an agreement.

The highlight line matters in practice. Most first drafts stall on cost or on gates, and the temptation is to write something vague to finish the page. The better move is to record the open question — 'we have not decided who pays for CI usage' — because the document's job is to make the team's actual state visible. Suggest revisiting the page after two weeks of real use; the sections that turned out wrong are the most valuable ones to have written down, because now the correction has somewhere to go.

Recap by connecting the two halves of the module: MCP extends the agent's reach into the tools the team already uses, and the team material — shared files, conventions, gates, cost, rollout — is what keeps that extended reach consistent and governable. Neither half works alone. Connected tools without a harness reproduce pixels and miss the system; a beautifully documented process with the agent still working from pasted screenshots leaves most of the value on the table.

Close the course honestly. Across seven modules, participants have gone from the design-code gap, through setup, mockup-to-code, prototyping, design systems, automation, and now integration and team practice. What the course has not done is supply taste, intent, or accountability — those stayed with the designer the whole way through, and the gates built in this module exist precisely because they do.

Point to where the practice continues. The Agentic Design Fundamentals course goes deeper on briefing, harnesses, and critique as platform-agnostic skills. The school's articles — MCP for Designers, Visual QA with Agents, the design-harness material — are kept current as servers and platforms move, which matters given how much of this module carried a June 2026 date stamp. The most useful next step, though, is not more reading: it is running the pilot, with the working agreement from the exercise as its first commit.