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:

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ý.