MCP — Model Context Protocol — pozwala agentom AI wykonywać wywołania narzędzi runtime do zewnętrznych serwisów. Figma dostarcza oficjalny serwer MCP, a społeczność zbudowała kilka kolejnych. Przekaz: Twój agent może pytać Figmę o dane projektowe bezpośrednio, na żądanie, w trakcie rozmowy. Bez kroku eksportu. Zawsze na żywo.

figmascope stawia przeciwny zakład architektoniczny: eksportuj raz, dostarcz pakiet, nigdy więcej się nie łącz. To naprawdę różne wybory z różnymi implikacjami. Oto, co każdy z nich faktycznie kosztuje i zyskuje.

Czym jest serwer Figma MCP

Model Context Protocol to otwarty standard Anthropic do łączenia agentów AI z zewnętrznymi narzędziami przez interfejs serwera. Serwer MCP udostępnia typowane narzędzia, które agent może wywoływać: "get_file", "get_node", "get_styles" i tak dalej. Gdy agent potrzebuje kontekstu projektu, wywołuje narzędzie, serwer MCP wywołuje API Figma, a wynik wraca jako kontekst dla bieżącego promptu.

Oficjalny serwer MCP Figmy pokrywa czytanie pliku, inspekcję węzłów, pobieranie komponentów i dostęp do komentarzy. Społecznościowe serwery MCP (jest kilka na GitHub) rozszerzają to niestandardowymi schematami, dodatkowymi transformacjami lub węższymi zakresami zoptymalizowanymi pod konkretne workflow agentów.

Aby używać dowolnego serwera Figma MCP, konfigurujesz go w kliencie agenta (Claude Desktop, Cursor, Continue itp.), podajesz PAT Figma i serwer działa jako lokalny proces. Gdy Twój agent potrzebuje kontekstu Figma, wywołuje narzędzie. Nie eksportujesz niczego jawnie — agent pobiera to, czego potrzebuje, gdy tego potrzebuje.

Model MCP w praktyce

Typowy workflow Figma z MCP wygląda tak: otwierasz Cursor, zaczynasz rozmowę, mówisz "zaimplementuj ekran kasy z tego pliku Figma" i agent wywołuje get_file, pobiera drzewo węzłów i ma dane projektu w kontekście. Jeśli potem powiesz "projektant zaktualizował tokeny przycisków", agent może ponownie wywołać i dostać świeże dane.

Ten model połączenia na żywo jest realny i atrakcyjny dla niektórych workflow. Agent pracuje z aktualnymi danymi. Nie zarządzasz artefaktami eksportu. Nie ma ręcznego kroku między "projektant wypchnął zmianę" a "agent ją ma".

Gdzie MCP wygrywa

Dane na żywo, bez kroku eksportu. Agent pobiera bieżący stan na żądanie. Jeśli projekt zmienił się dziesięć minut temu, agent może to zobaczyć. figmascope wymaga ręcznego ponownego eksportu, by uchwycić zmiany.

Konwersacyjna eksploracja projektu. "Jaki jest kolor przycisku CTA?" "Ile ekranów odwołuje się do tego komponentu?" Z MCP agent może odpowiedzieć wywołując Figmę. Z pakietem odpowiedź jest tylko tak świeża, jak ostatni eksport.

Bezpośrednia edycja Figmy. Niektóre serwery MCP udostępniają operacje zapisu — tworzenie węzłów, aktualizowanie właściwości, publikowanie komentarzy. To możliwe tylko z połączeniem na żywo. Statyczny pakiet nie ma ścieżki zapisu.

Bez ręcznego workflow. Dla deweloperów już korzystających z konfiguracji agentów połączonych przez MCP, brak kroku eksportu oznacza jedną rzecz mniej do zapomnienia. Zarządzanie kontekstem jest delegowane do agenta.

Gdzie MCP przegrywa

Model połączenia na żywo ma koszty architektoniczne, które łatwo bagatelizować.

Stan związany z sesją. Wywołania MCP odbywają się w kontekście sesji rozmowy. Dane pobrane przez agenta w sesji A nie są dostępne w sesji B bez ponownego pobierania. Jeśli zaczynasz nowy czat, agent zaczyna od nowa. Pakiet figmascope persystuje między sesjami, między deweloperami i między narzędziami — to po prostu pliki.

Niewidoczne dla gita. Nie ma artefaktu. Nic do commitowania. Kontekst projektu, który wpłynął na Twój kod, nie żyje w repozytorium. Za sześć miesięcy, jeśli chcesz zrozumieć, jak wyglądał projekt, gdy komponent był budowany — nie ma zapisu. Z pakietem w repo masz historię commitów intencji projektu.

Wymaga połączenia. MCP potrzebuje działającego serwera, żywego połączenia z API Figma i PAT z dostępem. Sieć niedostępna, API Figmy niedostępne, PAT wygasły — agent nie ma kontekstu. Pakiet działa w samolocie.

Pobieranie zależne od modelu. To, o co agent pyta przez MCP, zależy od tego, co zdecyduje się zapytać. Może nie pobrać wartości tokenów. Może nie pobrać inwentarza komponentów. Może zażądać tylko poddrzewa węzłów, które uważa za potrzebne, pomijając kontekst przestrzenny z sąsiednich węzłów. Pobieranie jest probabilistyczne, nie deterministyczne. figmascope pobiera wszystko, zawsze, ze stałym schematem.

Trudniejsze do testowania i odtwarzania. "Mój agent zbudował ten komponent z tych danych Figma w tym momencie" jest niemożliwe do zweryfikowania z MCP. Pobieranie jest efemeryczne. Z pakietem możesz odtworzyć dokładnie: ten sam pakiet, ten sam agent, ten sam prompt — deterministyczne wyjście. Ma to znaczenie przy debugowaniu, przeglądzie kodu i rozliczalności wydania.

Presja na okno kontekstu. Naiwne wywołanie get_file na złożonym pliku Figma zwraca ogromne drzewo JSON. Agenty muszą wykonywać selektywne wywołania narzędzi, by mieścić się w budżetach kontekstu. Wprowadza to heurystyki i osądy, które mogą iść źle. figmascope wstępnie przetwarza drzewo na strukturalny IR zawierający tylko to, co potrzebne, o znanych, ograniczonych rozmiarach.

Model pakietu figmascope: uchwyć raz, dostarczaj zawsze

figmascope eksportuje .zip zwykłych plików z Figma REST API — bez wtyczki, bez serwera, działa w przeglądarce. Pakiet zawiera:

Po wyeksportowaniu pakiet jest samowystarczalny i niezmienny. Trafia do repozytorium obok kodu, który opisuje. Dowolny agent, dowolna sesja, dowolny deweloper, dowolne zadanie CI może go czytać. Nie wymaga połączenia z niczym.

Wersjonowalne diffy: porównywanie pakietów jak kod

To najsilniejszy argument modelu pakietu. Ponieważ wyjście to strukturalny JSON i Markdown, można go diffować.

Eksportuj pakiet przed sprintem projektowym. Eksportuj kolejny po. Uruchom diff na tokens.json:

- "spacing.4": "16px"
+ "spacing.4": "14px"

To przełomowa zmiana w skali odstępów. Jest widoczna, przeglądalna i możliwa do prześledzenia do commitu. Z MCP ta sama zmiana dzieje się po cichu — następnym razem gdy agent pobierze, dostanie nową wartość, i nie ma zapisu, że cokolwiek się zmieniło.

Możesz uruchomić to jako bramę PR: eksportuj pakiet jako część design handoff, commituj go, wymagaj zatwierdzenia przez projektanta i deva na diffie przed rozpoczęciem implementacji. To specyfikacja projektu jako kod. MCP nie ma odpowiednika.

Argument determinizmu

Ta sama wersja pliku Figma + ten sam eksport figmascope = ten sam pakiet. Za każdym razem. Schemat IR jest stały. Logika pozyskiwania tokenów jest deterministyczna. Ekstrakcja kluczy ciągów jest oparta na regułach.

Pobieranie MCP nie jest deterministyczne. Agent decyduje, co pobierać. Różni agenci, różne sformułowanie promptu, różne budżety kontekstu — różne zachowanie pobierania. Wyjście jest zależne od modelu.

Dla codegen UI produkcji determinizm ma znaczenie. Chcesz, by specyfikacja, która wygenerowała komponent, była odtwarzalna. Chcesz być w stanie zregenerować komponent z tych samych danych wejściowych i uzyskać spójne wyniki. Pakiety to wspierają. Sesje MCP nie.

Porównanie

Wymiar Figma MCP Pakiet figmascope
Świeżość danych Zawsze na żywo — pobiera bieżący stan Figmy Migawka — tak świeża jak ostatni eksport
Wymagany krok eksportu Nie Tak — jednorazowy na wersję projektu
Kontrolowalny wersją Nie — brak artefaktu Tak — pakiet to diffable JSON + Markdown
Persystentny między sesjami Nie — musi ponownie pobierać każdą sesję Tak — pliki persystują w nieskończoność
Działa offline Nie Tak
Deterministyczne wyjście Nie — pobieranie zależne od modelu Tak — te same dane wejściowe → ten sam pakiet zawsze
Presja na okno kontekstu Wysoka — surowy JSON Figmy jest duży i nieustrukturyzowany Niska — IR jest wstępnie przetworzony, ograniczony rozmiar
Operacje zapisu na Figmie Tak (niektóre serwery MCP) Nie — tylko eksport do odczytu
Specyfikacja projektu w historii gita Nie Tak — commituj pakiet, śledź historię projektu
Wymagana konfiguracja agenta Tak — konfiguruj serwer MCP per klient agenta Nie — dowolny agent czytający pliki działa
Klucze i18n ciągów Nie w bazowym schemacie Figma MCP Tak — stringRef.key w IR + strings.json
Przestrzenne / układowe IR Surowe drzewo węzłów Figmy (bez semantycznych typów układu) Typowane IR: stack / overlay / absolute / leaf
Pozyskiwanie tokenów Variables jeśli ustawione; w przeciwnym razie surowe wartości Variables → wnioskowane z częstotliwości → brak

MCP świeci dla "edytuj Figmę na żywo" — pakiety świecą dla "buduj UI produkcji"

To uczciwe podsumowanie. Jeśli Twój workflow to konwersacyjna eksploracja projektu — "zmień ten komponent", "adnotuj ten ekran", "jakie są tokeny kolorów na tej ramce" — model połączenia na żywo MCP jest właściwy. Agent jest współpracownikiem w procesie projektowania i potrzebuje aktualnych danych, by to robić.

Jeśli Twój workflow to budowanie UI produkcji ze sfinalizowanego (lub bliskiego finalizacji) projektu — implementowanie komponentów, podłączanie stanu, pisanie testów — model pakietu jest lepszy. Chcesz specyfikacji zakotwiczonej w repozytorium, diffable między iteracjami projektu, czytelnej przez dowolnego agenta bez konfiguracji i wystarczająco deterministycznej, by na niej budować.

Oba modele są komplementarne. Używaj MCP gdy projekt jest w fazie zmiany i iterujesz wspólnie. Eksportuj pakiet figmascope, gdy projekt jest stabilny i przekazujesz go inżynierom do implementacji. Pakiet staje się źródłem prawdy, przeciwko któremu budowana jest implementacja — możliwym do prześledzenia, przeglądowym, odtwarzalnym.