MCP — Model Context Protocol — umožňuje AI agentům za běhu volat nástroje externích služeb. Figma dodává oficiální MCP server a komunita jich vytvořila několik dalších. Příslib: váš agent může od Figmy přímo na vyžádání získat designová data, uprostřed konverzace. Žádný krok exportu. Vždy aktuální.
figmascope vsází na opačnou architektonickou strategii: exportovat jednou, odeslat balíček, již se nikdy nepřipojovat. Jedná se o skutečně odlišné volby s odlišnými dopady. Zde je přehled toho, co každá z nich skutečně stojí a přináší.
Co je Figma MCP server
Model Context Protocol je otevřený standard Anthropicu pro připojení AI agentů k externím nástrojům prostřednictvím serverového rozhraní. MCP server zpřístupňuje typované nástroje, které agent může volat: „get_file," „get_node," „get_styles" a tak dále. Když agent potřebuje designový kontext, zavolá nástroj, MCP server zavolá Figma API a výsledek se vrátí jako kontext pro aktuální prompt.
Oficiální MCP server od Figmy pokrývá čtení souborů, inspekci uzlů, načítání komponent a přístup ke komentářům. Komunitní MCP servery (na GitHubu je jich několik) toto rozšiřují o vlastní schémata, další transformace nebo užší rozsahy optimalizované pro specifické pracovní postupy agentů.
Chcete-li použít libovolný Figma MCP server, nakonfigurujte ho ve svém klientu agenta (Claude Desktop, Cursor, Continue atd.), zadejte Figma PAT a server běží jako lokální proces. Když váš agent potřebuje kontext Figmy, zavolá nástroj. Explicitně nic neexportujete — agent načítá to, co potřebuje, když to potřebuje.
MCP model v praxi
Typický pracovní postup s MCP pro Figmu vypadá takto: otevřete Cursor, začnete konverzaci, řeknete „implementuj obrazovku pokladny z tohoto souboru Figma" a agent zavolá get_file, načte strom uzlů a má designová data v kontextu. Pokud pak řeknete „designér aktualizoval tokeny tlačítek," agent může znovu zavolat a získat čerstvá data.
Tento model živého připojení je skutečný a přesvědčivý pro některé pracovní postupy. Agent pracuje s aktuálními daty. Nespravujete artefakty exportu. Mezi „designér odeslal změnu" a „agent ji má" není žádný manuální krok.
Kde MCP vítězí
Živá data, žádný krok exportu. Agent na vyžádání načítá aktuální stav. Pokud se design změnil před deseti minutami, agent to může vidět. figmascope vyžaduje manuální opětovný export, aby zachytil změny.
Konverzační průzkum designu. „Jaká je barva tlačítka CTA?" „Kolik obrazovek odkazuje na tuto komponentu?" S MCP může agent odpovědět voláním Figmy. S balíčkem je odpověď jen tak čerstvá jako poslední export.
Přímá úprava Figmy. Některé MCP servery zpřístupňují operace zápisu — vytvářet uzly, aktualizovat vlastnosti, zveřejňovat komentáře. To je možné pouze s živým připojením. Statický balíček nemá cestu zápisu.
Žádný manuální pracovní postup. Pro vývojáře, kteří již používají nastavení agentů s MCP připojením, žádný krok exportu znamená jednu věc méně, na kterou lze zapomenout. Správa kontextu je delegována na agenta.
Kde MCP prohrává
Model živého připojení má architektonické náklady, které je snadné podcenit.
Stav vázaný na relaci. Volání MCP probíhají v kontextu konverzační relace. Data, která agent načetl v relaci A, nejsou dostupná v relaci B bez opětovného načtení. Pokud začnete nový chat, agent začíná znovu. Balíček figmascope přetrvává mezi relacemi, mezi vývojáři i mezi nástroji — jsou to jen soubory.
Neviditelné pro git. Neexistuje žádný artefakt. Nic ke commitu. Designový kontext, který informoval váš kód, nežije v repozitáři. Za šest měsíců, pokud budete chtít pochopit, jak design vypadal při vytváření komponenty, neexistuje žádný záznam. S balíčkem v repozitáři máte historii commitů záměrů designu.
Vyžaduje připojení. MCP potřebuje běžící server, živé připojení k Figma API a PAT s přístupem. Výpadek sítě, výpadek Figma API, vypršení PAT — agent nemá žádný kontext. Balíček funguje i v letadle.
Na modelu závislé načítání. To, co agent přes MCP požaduje, závisí na tom, co se rozhodne požádat. Možná nenačte hodnoty tokenů. Možná nenačte inventář komponent. Možná požádá pouze o podstrom uzlů, o kterém si myslí, že ho potřebuje, a tím přehlédne prostorový kontext ze sousedních uzlů. Načítání je pravděpodobnostní, nikoli deterministické. figmascope načítá vše, pokaždé, s pevným schématem.
Obtížnější testování a reprodukce. „Můj agent postavil tuto komponentu z těchto dat Figmy v tomto okamžiku" není s MCP ověřitelné. Načtení je pomíjivé. S balíčkem lze přesně přehrát: stejný balíček, stejný agent, stejný prompt — deterministický výstup. To je důležité pro ladění, revizi kódu a odpovědnost za vydání.
Tlak na kontextové okno. Naivní volání get_file na složitém souboru Figma vrací obrovský JSON strom. Agenti musí provádět selektivní volání nástrojů, aby zůstali v rámci kontextových rozpočtů. To zavádí heuristiky a úsudky, které mohou jít špatným směrem. figmascope předem zpracovává strom do strukturovaného IR pouze s tím, co je potřeba, ve známé, omezené velikosti.
Model balíčku figmascope: zachytit jednou, odesílat navždy
figmascope exportuje .zip prostých souborů z Figma REST API — žádný plugin, žádný server, běží ve vašem prohlížeči. Balíček obsahuje:
CONTEXT.md— specifikace čitelná pro člověka i agentatokens.json— typované designové tokeny, kaskádové zdroje: Figma variables → odvozené z frekvence → žádnéscreens/*.json— IR pro každou obrazovku se sémantikou rozvržení: stack, overlay, absolute, leaf;componentIdna uzlech INSTANCE;stringRef.keyna textuscreens/*.png— referenční snímky obrazovky 2×components/inventory.json— úplný index komponentstrings.json— veškerý textový obsah, klíčovaný_meta.json— metadata exportu
Po exportu je balíček soběstačný a neměnný. Jde do vašeho repozitáře spolu s kódem, který popisuje. Jakýkoli agent, jakákoli relace, jakýkoli vývojář, jakákoli CI úloha ho může číst. Není vyžadováno žádné připojení.
Verzovatelné diffa: porovnávání balíčků jako kódu
Toto je nejsilnější argument modelu balíčku. Protože výstup je strukturovaný JSON a Markdown, lze ho porovnat pomocí diff.
Exportujte balíček před designovým sprintem. Exportujte další po něm. Spusťte diff na tokens.json:
- "spacing.4": "16px"
+ "spacing.4": "14px"
To je zlomová změna ve vaší škále mezer. Je viditelná, přezkoumatelná a sledovatelná ke commitu. S MCP se stejná změna stane tiše — příště, když agent načte, získá novou hodnotu a neexistuje žádný záznam o tom, že se cokoliv změnilo.
Toto lze spustit jako bránu PR: exportujte balíček jako součást design handoff, odevzdejte ho, požadujte souhlas designéra i vývojáře s diffem před zahájením implementace. To je design-spec-as-code. MCP nemá ekvivalent.
Argument determinismu
Stejná verze souboru Figma + stejný export figmascope = stejný balíček. Pokaždé. Schéma IR je pevné. Logika sourcing tokenů je deterministická. Extrakce klíčů řetězců je pravidlová.
Načítání MCP není deterministické. Agent rozhoduje, co načíst. Různí agenti, různé formulování promptu, různé kontextové rozpočty — různé chování načítání. Výstup závisí na modelu.
Pro produkční generování kódu UI záleží na determinismu. Chcete, aby specifikace, která vygenerovala komponentu, byla reprodukovatelná. Chcete být schopni znovu vygenerovat komponentu ze stejných vstupů a získat konzistentní výsledky. Balíčky to podporují. MCP relace ne.
Srovnání
| Dimenze | Figma MCP | balíček figmascope |
|---|---|---|
| Čerstvost dat | Vždy živá — načítá aktuální stav Figmy | Snímek — tak čerstvý jako poslední export |
| Vyžaduje krok exportu | Ne | Ano — jednorázově na verzi designu |
| Verzovatelný | Ne — žádný artefakt | Ano — balíček je diffovatelný JSON + Markdown |
| Přetrvává napříč relacemi | Ne — nutno opětovně načíst každou relaci | Ano — soubory přetrvávají neomezeně |
| Funguje offline | Ne | Ano |
| Deterministický výstup | Ne — načítání závislé na modelu | Ano — stejný vstup → vždy stejný balíček |
| Tlak na kontextové okno | Vysoký — raw Figma JSON je velký a nestrukturovaný | Nízký — IR je předem zpracovaný, omezená velikost |
| Operace zápisu na Figmu | Ano (některé MCP servery) | Ne — pouze export pro čtení |
| Design specifikace v historii git | Ne | Ano — commitujte balíček, sledujte historii designu |
| Vyžaduje nastavení agenta | Ano — nakonfigurujte MCP server pro každého klienta agenta | Ne — funguje jakýkoli agent, který čte soubory |
| Klíče i18n řetězců | Nejsou v základním schématu Figma MCP | Ano — stringRef.key v IR + strings.json |
| Prostorový / layoutový IR | Raw strom uzlů Figmy (bez sémantických typů rozvržení) | Typovaný IR: stack / overlay / absolute / leaf |
| Sourcing tokenů | Variables pokud nastaveny; jinak raw hodnoty | Variables → odvozené z frekvence → žádné |
MCP vyniká pro „živou úpravu Figmy" — balíčky vynikají pro „tvorbu produkčního UI"
Toto je upřímné shrnutí. Pokud je váš pracovní postup konverzační průzkum designu — „změňte tuto komponentu," „okomentujte tuto obrazovku," „jaké jsou tokeny barev na tomto rámci" — model živého připojení MCP je ten správný. Agent je spolupracovník v procesu designu a potřebuje aktuální data, aby to mohl dělat.
Pokud je váš pracovní postup vytváření produkčního UI z finalizovaného (nebo téměř finalizovaného) designu — implementace komponent, zapojení stavu, psaní testů — model balíčku je lepší. Chcete specifikaci ukotvenou ve vašem repozitáři, diffovatelnou napříč iteracemi designu, čitelnou jakýmkoli agentem bez konfigurace a dostatečně deterministickou, aby na ní bylo možné stavět.
Oba modely se doplňují. Používejte MCP, když je design ve vývoji a iterujete kolaborativně. Exportujte balíček figmascope, když je design stabilní a předáváte ho inženýrům k implementaci. Balíček se stává zdrojem pravdy, proti kterému je implementace postavena — sledovatelný, přezkoumatelný, reprodukovatelný.