figmascope vs Figma MCP
Serververbinding of gewone bestanden?

MCP — Model Context Protocol — laat AI-agents tijdens runtime tool-aanroepen doen naar externe diensten. Figma levert een officiële MCP-server, en de community heeft er meerdere gebouwd. De pitch: je agent kan Figma direct om ontwerpdata vragen, op aanvraag, midden in een gesprek. Geen exportstap. Altijd live.

figmascope neemt de tegenovergestelde architecturele gok: eenmalig exporteren, een bundel verzenden, nooit meer verbinden. Dit zijn werkelijk verschillende keuzes met verschillende implicaties. Hier is wat elke keuze werkelijk kost en oplevert.

Wat de MCP-server van Figma is

Model Context Protocol is de open standaard van Anthropic voor het verbinden van AI-agents met externe tools via een serverinterface. Een MCP-server stelt getypeerde tools bloot die de agent kan aanroepen: "get_file," "get_node," "get_styles," enzovoort. Wanneer de agent ontwerpcontext nodig heeft, roept het de tool aan, de MCP-server roept de Figma API aan, en het resultaat komt terug als context voor de huidige prompt.

De officiële MCP-server van Figma dekt het lezen van bestanden, node-inspectie, componentophaling en toegang tot opmerkingen. Community MCP-servers (er zijn er meerdere op GitHub) breiden dit uit met aangepaste schema's, extra transformaties of engere scopes geoptimaliseerd voor specifieke agent-workflows.

Om een Figma MCP-server te gebruiken, configureer je het in je agentclient (Claude Desktop, Cursor, Continue, etc.), verstrek je een Figma PAT, en de server draait als een lokaal proces. Wanneer je agent Figma-context nodig heeft, roept het de tool aan. Je exporteert expliciet niets — de agent haalt op wat het nodig heeft wanneer het nodig is.

Het MCP-model in de praktijk

Een typische MCP-aangedreven Figma-workflow ziet er zo uit: je opent Cursor, start een gesprek, zegt "implementeer het uitbetalingsscherm uit dit Figma-bestand," en de agent roept get_file aan, haalt de nodeboom op en heeft de ontwerpdata in de context. Als je vervolgens zegt "de ontwerper heeft de knooptokens bijgewerkt," kan de agent opnieuw aanroepen en nieuwe data ophalen.

Dit live-verbindingsmodel is echt en overtuigend voor sommige workflows. De agent werkt met actuele data. Je beheert geen exportartefacten. Er is geen handmatige stap tussen "ontwerper pustte een wijziging" en "agent heeft het."

Waar MCP uitblinkt

Live data, geen exportstap. De agent haalt de huidige status op aanvraag op. Als het ontwerp tien minuten geleden is veranderd, kan de agent het zien. figmascope vereist een handmatige herexport om wijzigingen vast te leggen.

Conversationele ontwerpverkenning. "Wat is de kleur van de CTA-knop?" "Hoeveel schermen verwijzen naar dit component?" Met MCP kan een agent deze beantwoorden door Figma aan te roepen. Met een bundel is het antwoord alleen zo actueel als de laatste export.

Figma direct bewerken. Sommige MCP-servers bieden schrijfoperaties — nodes aanmaken, eigenschappen bijwerken, opmerkingen plaatsen. Dit is alleen mogelijk met een live verbinding. Een statische bundel heeft geen schrijfpad.

Geen handmatige workflow. Voor ontwikkelaars die al MCP-verbonden agent-setups gebruiken, betekent geen exportstap één ding minder om te vergeten. Het contextbeheer wordt gedelegeerd aan de agent.

Waar MCP tekortschiet

Het live-verbindingsmodel heeft architecturele kosten die gemakkelijk worden onderschat.

Sessiegebonden staat. MCP-aanroepen vinden plaats in de context van een gesprekssessie. De data die de agent in sessie A heeft opgehaald, is niet beschikbaar in sessie B zonder opnieuw op te halen. Als je een nieuw gesprek start, begint de agent opnieuw. Een figmascope-bundel blijft bestaan tussen sessies, tussen ontwikkelaars en tussen tools — het zijn gewoon bestanden.

Ondoorzichtig voor git. Er is geen artefact. Niets om te committen. De ontwerpcontext die je code heeft geïnformeerd, leeft niet in de repository. Over zes maanden, als je wilt begrijpen hoe het ontwerp eruitzag toen een component werd gebouwd, is er geen record. Met een bundel in de repository heb je een commitgeschiedenis van ontwerpintentie.

Vereist verbinding. MCP heeft een draaiende server, een live Figma API-verbinding en een PAT met toegang nodig. Netwerk uitgevallen, Figma API uitgevallen, PAT verlopen — de agent heeft geen context. Een bundel werkt in een vliegtuig.

Modelafhankelijke ophaling. Wat de agent via MCP opvraagt, hangt af van wat het besluit te vragen. Mogelijk haalt het de tokenwaarden niet op. Mogelijk haalt het de componentinventaris niet op. Mogelijk vraagt het alleen de nodesubboom op waarvan het denkt dat het die nodig heeft, waarbij het ruimtelijke context van aangrenzende nodes mist. De ophaling is probabilistisch, niet deterministisch. figmascope haalt alles op, elke keer, met een vast schema.

Moeilijker te testen en reproduceren. "Mijn agent bouwde dit component uit deze Figma-data op dit tijdstip" is niet verifieerbaar met MCP. De ophaling is efemeer. Met een bundel kun je precies herspelen: dezelfde bundel, dezelfde agent, dezelfde prompt — deterministische uitvoer. Dit is belangrijk voor debuggen, codereviews en release-verantwoording.

Druk op het contextvenster. Een naïeve get_file-aanroep op een complex Figma-bestand retourneert een enorme JSON-boom. Agents moeten selectieve tool-aanroepen doen om binnen contextbudgetten te blijven. Dit introduceert heuristieken en oordeelsoproepen die fout kunnen gaan. figmascope verwerkt de boom voor in een gestructureerde IR met alleen wat nodig is, van een bekende, begrensde grootte.

Het bundelmodel van figmascope: eenmalig vastleggen, altijd verzenden

figmascope exporteert een .zip van gewone bestanden uit de Figma REST API — geen plugin, geen server, draait in je browser. De bundel bevat:

• CONTEXT.md — voor mensen en machines leesbare specificatie
• tokens.json — getypeerde ontwerptokens, trapsgewijze bronnen: Figma Variables → afgeleid uit frequentie → geen
• screens/*.json — per-scherm IR met layoutsemantiek: stack, overlay, absolute, leaf; componentId op INSTANCE-nodes; stringRef.key op tekst
• screens/*.png — 2× referentieschermafbeeldingen
• components/inventory.json — volledige componentindex
• strings.json — alle tekstinhoud, gesleuteld
• _meta.json — exportmetadata

Eenmaal geëxporteerd is de bundel op zichzelf staand en onveranderlijk. Hij gaat in je repository naast de code die hij beschrijft. Elke agent, elke sessie, elke ontwikkelaar, elke CI-taak kan hem lezen. Geen verbinding met iets nodig.

Versioneerbare diffs: bundels vergelijken zoals code

Dit is het sterkste argument van het bundelmodel. Omdat de uitvoer gestructureerde JSON en Markdown is, kun je het diffen.

Exporteer een bundel voor een ontwerpspriet. Exporteer er een na. Voer diff uit op tokens.json:

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

Dat is een brekende wijziging in je tussenruimteschaal. Het is zichtbaar, reviseerbaar en traceerbaar naar een commit. Met MCP gebeurt dezelfde wijziging stilzwijgend — de volgende keer dat de agent ophaalt, krijgt het de nieuwe waarde, en er is geen record dat er iets is veranderd.

Je kunt dit uitvoeren als een PR-poort: exporteer de bundel als onderdeel van de ontwerpoverdracht, commit hem, vereist ondertekening door ontwerper en ontwikkelaar op de diff voordat de implementatie begint. Dat is ontwerp-specificatie-als-code. MCP heeft geen equivalent.

Determinismeargument

Dezelfde Figma-bestandsversie + dezelfde figmascope-export = dezelfde bundel. Elke keer. Het IR-schema is vast. De tokenbronlogica is deterministisch. De stringsleutelextractie is regelgebaseerd.

MCP-ophaling is niet deterministisch. De agent beslist wat hij ophaalt. Verschillende agents, verschillende promptformulering, verschillende contextbudgetten — ander ophaalgedrag. De uitvoer is modelafhankelijk.

Voor productie-UI-codegeneratie is determinisme belangrijk. Je wilt dat de specificatie die een component heeft gegenereerd reproduceerbaar is. Je wilt het component opnieuw kunnen genereren uit dezelfde invoer en consistente resultaten krijgen. Bundels ondersteunen dit. MCP-sessies niet.

Vergelijking

MCP schittert voor "bewerk Figma live" — bundels schitteren voor "bouw productie-UI"

Dit is de eerlijke samenvatting. Als je workflow conversationele ontwerpverkenning is — "verander dit component," "annoteer dit scherm," "wat zijn de kleurtokens op dit frame" — is de live verbinding van MCP het juiste model. De agent is een medewerker in het ontwerpproces, en het heeft actuele data nodig om dat te doen.

Als je workflow productie-UI bouwt vanuit een gefinaliseerd (of bijna gefinaliseerd) ontwerp — componenten implementeren, state indraden, tests schrijven — is het bundelmodel beter. Je wilt de specificatie verankerd in je repository, diffbaar over ontwerpiteraties, leesbaar door elke agent zonder configuratie, en deterministisch genoeg om op te bouwen.

De twee modellen zijn complementair. Gebruik MCP wanneer het ontwerp in flux is en je iteratief samenwerkt. Exporteer een figmascope-bundel wanneer het ontwerp stabiel is en je het aan engineers geeft voor implementatie. De bundel wordt de bron van waarheid waarop de implementatie wordt gebouwd — traceerbaar, reviseerbaar, reproduceerbaar.