MCP — Model Context Protocol — lets AI agents make runtime tool calls to external services. Figma ships an official MCP server, and the community has built several more. The pitch: your agent can ask Figma for design data directly, on demand, mid-conversation. No export step. Always live.
figmascope takes the opposite architectural bet: export once, ship a bundle, never connect again. These are genuinely different choices with different implications. Here's what each one actually costs and gains.
What Figma's MCP server is
Model Context Protocol is Anthropic's open standard for connecting AI agents to external tools via a server interface. An MCP server exposes typed tools the agent can call: "get_file," "get_node," "get_styles," and so on. When the agent needs design context, it calls the tool, the MCP server calls the Figma API, and the result comes back as context for the current prompt.
Figma's official MCP server covers file reading, node inspection, component retrieval, and comment access. Community MCP servers (there are several on GitHub) extend this with custom schemas, additional transformations, or narrower scopes optimized for specific agent workflows.
To use any Figma MCP server, you configure it in your agent client (Claude Desktop, Cursor, Continue, etc.), provide a Figma PAT, and the server runs as a local process. When your agent needs Figma context, it calls the tool. You don't explicitly export anything — the agent fetches what it needs when it needs it.
The MCP model in practice
A typical MCP-powered Figma workflow looks like this: you open Cursor, start a conversation, say "implement the checkout screen from this Figma file," and the agent calls get_file, pulls the node tree, and has the design data in context. If you then say "the designer updated the button tokens," the agent can call again and get fresh data.
This live-connection model is real and compelling for some workflows. The agent is working with current data. You don't manage export artifacts. There's no manual step between "designer pushed a change" and "agent has it."
Where MCP wins
Live data, no export step. The agent fetches current state on demand. If the design changed ten minutes ago, the agent can see it. figmascope requires a manual re-export to capture changes.
Conversational design exploration. "What's the color of the CTA button?" "How many screens reference this component?" With MCP, an agent can answer these by calling Figma. With a bundle, the answer is only as fresh as the last export.
Editing Figma directly. Some MCP servers expose write operations — create nodes, update properties, post comments. This is only possible with a live connection. A static bundle has no write path.
No manual workflow. For developers who are already using MCP-connected agent setups, no export step means one less thing to forget. The context management is delegated to the agent.
Where MCP loses
The live-connection model has architectural costs that are easy to underestimate.
Session-bound state. MCP calls happen in the context of a conversation session. The data the agent retrieved in session A is not available in session B without re-fetching. If you start a new chat, the agent starts fresh. A figmascope bundle persists between sessions, between developers, and between tools — it's just files.
Opaque to git. There is no artifact. Nothing to commit. The design context that informed your code does not live in the repository. Six months from now, if you want to understand what the design looked like when a component was built, there's no record. With a bundle in the repo, you have a commit history of design intent.
Requires connection. MCP needs a running server, a live Figma API connection, and a PAT with access. Network down, Figma API down, PAT expired — the agent has no context. A bundle works on a plane.
Model-dependent retrieval. What the agent asks for via MCP depends on what it decides to ask for. It might not fetch the token values. It might not pull the component inventory. It might request only the node subtree it thinks it needs, missing spatial context from adjacent nodes. The retrieval is probabilistic, not deterministic. figmascope fetches everything, every time, with a fixed schema.
Harder to test and reproduce. "My agent built this component from this Figma data at this point in time" is not verifiable with MCP. The fetch is ephemeral. With a bundle, you can replay exactly: same bundle, same agent, same prompt — deterministic output. This matters for debugging, code review, and release accountability.
Context window pressure. A naive get_file call on a complex Figma file returns an enormous JSON tree. Agents have to make selective tool calls to stay within context budgets. This introduces heuristics and judgment calls that can go wrong. figmascope pre-processes the tree into a structured IR with only what's needed, at a known, bounded size.
figmascope's bundle model: capture once, ship forever
figmascope exports a .zip of plain files from the Figma REST API — no plugin, no server, runs in your browser. The bundle contains:
CONTEXT.md— human-readable spec, agent-readable spectokens.json— typed design tokens, cascading sources: Figma variables → inferred from frequency → nonescreens/*.json— per-screen IR with layout semantics: stack, overlay, absolute, leaf;componentIdon INSTANCE nodes;stringRef.keyon textscreens/*.png— 2× reference screenshotscomponents/inventory.json— full component indexstrings.json— all text content, keyed_meta.json— export metadata
Once exported, the bundle is self-contained and immutable. It goes in your repo alongside the code it describes. Any agent, any session, any developer, any CI job can read it. No connection to anything required.
Versionable diffs: comparing bundles like code
This is the bundle model's strongest argument. Because the output is structured JSON and Markdown, you can diff it.
Export a bundle before a design sprint. Export another after. Run diff on tokens.json:
- "spacing.4": "16px"
+ "spacing.4": "14px"
That's a breaking change in your spacing scale. It's visible, reviewable, and traceable to a commit. With MCP, the same change happens silently — the next time the agent fetches, it gets the new value, and there's no record that anything changed.
You can run this as a PR gate: export the bundle as part of design handoff, commit it, require designer and dev sign-off on the diff before implementation starts. That's design-spec-as-code. MCP has no equivalent.
Determinism argument
Same Figma file version + same figmascope export = same bundle. Every time. The IR schema is fixed. The token sourcing logic is deterministic. The string key extraction is rule-based.
MCP retrieval is not deterministic. The agent decides what to fetch. Different agents, different prompt phrasing, different context budgets — different fetch behavior. The output is model-dependent.
For production UI codegen, determinism matters. You want the spec that generated a component to be reproducible. You want to be able to regenerate the component from the same inputs and get consistent results. Bundles support this. MCP sessions don't.
Comparison
| Dimension | Figma MCP | figmascope bundle |
|---|---|---|
| Data freshness | Always live — fetches current Figma state | Snapshot — as fresh as last export |
| Export step required | No | Yes — one-time per design version |
| Version controllable | No — no artifact | Yes — bundle is diffable JSON + Markdown |
| Persistent across sessions | No — must re-fetch each session | Yes — files persist indefinitely |
| Works offline | No | Yes |
| Deterministic output | No — model-dependent retrieval | Yes — same input → same bundle always |
| Context window pressure | High — raw Figma JSON is large and unstructured | Low — IR is pre-processed, bounded size |
| Write operations on Figma | Yes (some MCP servers) | No — read-only export |
| Design spec in git history | No | Yes — commit bundle, trace design history |
| Agent setup required | Yes — configure MCP server per agent client | No — any agent that reads files works |
| i18n string keys | Not in base Figma MCP schema | Yes — stringRef.key in IR + strings.json |
| Spatial / layout IR | Raw Figma node tree (no semantic layout types) | Typed IR: stack / overlay / absolute / leaf |
| Token sourcing | Variables if set; otherwise raw values | Variables → inferred from frequency → none |
MCP shines for "edit Figma live" — bundles shine for "build production UI"
This is the honest summary. If your workflow is conversational design exploration — "change this component," "annotate this screen," "what are the color tokens on this frame" — MCP's live connection is the right model. The agent is a collaborator in the design process, and it needs current data to do that.
If your workflow is building production UI from a finalized (or near-finalized) design — implementing components, wiring up state, writing tests — the bundle model is better. You want the spec anchored in your repo, diffable across design iterations, readable by any agent without configuration, and deterministic enough to build on.
The two models are complementary. Use MCP when the design is in flux and you're iterating collaboratively. Export a figmascope bundle when the design is stable and you're handing it to engineers for implementation. The bundle becomes the source of truth that the implementation is built against — traceable, reviewable, reproducible.