MCP — Model Context Protocol — permette agli agenti AI di fare chiamate a strumenti esterni a runtime. Figma fornisce un server MCP ufficiale, e la community ne ha costruiti diversi altri. Il pitch: il tuo agente può chiedere a Figma i dati di design direttamente, su richiesta, a metà conversazione. Nessun passaggio di esportazione. Sempre live.

figmascope fa la scommessa architetturale opposta: esporta una volta, fornisce un bundle, non si connette mai più. Queste sono scelte genuinamente diverse con implicazioni diverse. Ecco cosa costa e guadagna realmente ciascuna.

Cos'è il server MCP di Figma

Model Context Protocol è lo standard aperto di Anthropic per connettere gli agenti AI a strumenti esterni tramite un'interfaccia server. Un server MCP espone strumenti tipizzati che l'agente può chiamare: "get_file," "get_node," "get_styles," e così via. Quando l'agente ha bisogno di contesto di design, chiama lo strumento, il server MCP chiama l'API di Figma e il risultato torna come contesto per il prompt corrente.

Il server MCP ufficiale di Figma copre la lettura di file, l'ispezione dei nodi, il recupero dei componenti e l'accesso ai commenti. I server MCP della community (ce ne sono diversi su GitHub) estendono questo con schemi personalizzati, trasformazioni aggiuntive o ambiti più ristretti ottimizzati per specifici flussi di lavoro degli agenti.

Per usare qualsiasi server MCP Figma, lo configuri nel tuo client agente (Claude Desktop, Cursor, Continue, ecc.), fornisci un PAT Figma, e il server gira come processo locale. Quando il tuo agente ha bisogno di contesto Figma, chiama lo strumento. Non esporti esplicitamente nulla — l'agente recupera ciò di cui ha bisogno quando ne ha bisogno.

Il modello MCP in pratica

Un tipico flusso di lavoro Figma con MCP appare così: apri Cursor, inizi una conversazione, dici "implementa la schermata checkout da questo file Figma," e l'agente chiama get_file, recupera l'albero dei nodi e ha i dati di design nel contesto. Se poi dici "il designer ha aggiornato i token del pulsante," l'agente può chiamare di nuovo e ottenere dati aggiornati.

Questo modello di connessione live è reale e convincente per alcuni flussi di lavoro. L'agente lavora con dati correnti. Non gestisci artefatti di esportazione. Non c'è nessun passaggio manuale tra "il designer ha inviato una modifica" e "l'agente ce l'ha."

Dove vince MCP

Dati live, nessun passaggio di esportazione. L'agente recupera lo stato corrente su richiesta. Se il design è cambiato dieci minuti fa, l'agente può vederlo. figmascope richiede una riesportazione manuale per catturare le modifiche.

Esplorazione conversazionale del design. "Qual è il colore del pulsante CTA?" "Quante schermate fanno riferimento a questo componente?" Con MCP, un agente può rispondere chiamando Figma. Con un bundle, la risposta è aggiornata solo quanto l'ultima esportazione.

Modifica diretta di Figma. Alcuni server MCP espongono operazioni di scrittura — creare nodi, aggiornare proprietà, pubblicare commenti. Questo è possibile solo con una connessione live. Un bundle statico non ha nessun percorso di scrittura.

Nessun flusso di lavoro manuale. Per gli sviluppatori che usano già setup di agenti connessi via MCP, nessun passaggio di esportazione significa una cosa in meno da dimenticare. La gestione del contesto è delegata all'agente.

Dove perde MCP

Il modello di connessione live ha costi architetturali facili da sottovalutare.

Stato legato alla sessione. Le chiamate MCP avvengono nel contesto di una sessione di conversazione. I dati che l'agente ha recuperato nella sessione A non sono disponibili nella sessione B senza ri-recuperarli. Se inizi una nuova chat, l'agente ricomincia da zero. Un bundle di figmascope persiste tra sessioni, tra sviluppatori e tra strumenti — sono solo file.

Opaco per git. Non c'è nessun artefatto. Nulla da committare. Il contesto di design che ha informato il tuo codice non vive nel repository. Sei mesi dopo, se vuoi capire come appariva il design quando è stato costruito un componente, non c'è nessun record. Con un bundle nel repo, hai una cronologia dei commit dell'intento di design.

Richiede connessione. MCP ha bisogno di un server in esecuzione, una connessione live all'API Figma e un PAT con accesso. Rete giù, API Figma giù, PAT scaduto — l'agente non ha contesto. Un bundle funziona in aereo.

Recupero dipendente dal modello. Ciò che l'agente chiede tramite MCP dipende da cosa decide di chiedere. Potrebbe non recuperare i valori dei token. Potrebbe non recuperare l'inventario dei componenti. Potrebbe richiedere solo il sottoalbero dei nodi che pensa di aver bisogno, mancando il contesto spaziale dei nodi adiacenti. Il recupero è probabilistico, non deterministico. figmascope recupera tutto, ogni volta, con uno schema fisso.

Più difficile da testare e riprodurre. "Il mio agente ha costruito questo componente da questi dati Figma in questo momento" non è verificabile con MCP. Il recupero è effimero. Con un bundle, puoi riprodurre esattamente: stesso bundle, stesso agente, stesso prompt — output deterministico. Questo è importante per il debugging, la revisione del codice e la responsabilità di rilascio.

Pressione sulla finestra di contesto. Una chiamata get_file ingenua su un file Figma complesso restituisce un enorme albero JSON. Gli agenti devono fare chiamate a strumenti selettive per rimanere entro i budget di contesto. Questo introduce euristiche e giudizi di valore che possono andare storto. figmascope pre-elabora l'albero in un IR strutturato con solo ciò che è necessario, a una dimensione nota e limitata.

Il modello bundle di figmascope: cattura una volta, distribuisci per sempre

figmascope esporta un .zip di file semplici dalla REST API di Figma — nessun plugin, nessun server, gira nel tuo browser. Il bundle contiene:

Una volta esportato, il bundle è autocontenuto e immutabile. Va nel tuo repo accanto al codice che descrive. Qualsiasi agente, qualsiasi sessione, qualsiasi sviluppatore, qualsiasi job CI può leggerlo. Nessuna connessione a nulla necessaria.

Diff versionabili: confrontare i bundle come codice

Questo è l'argomento più forte del modello bundle. Poiché l'output è JSON strutturato e Markdown, puoi confrontarlo con diff.

Esporta un bundle prima di uno sprint di design. Esportane un altro dopo. Esegui diff su tokens.json:

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

Questa è una modifica breaking nella tua scala di spaziatura. È visibile, revisionabile e tracciabile a un commit. Con MCP, la stessa modifica avviene silenziosamente — la prossima volta che l'agente recupera, ottiene il nuovo valore, e non c'è nessun record che qualcosa sia cambiato.

Puoi eseguire questo come un gate per PR: esporta il bundle come parte dell'handoff del design, committalo, richiedi l'approvazione del designer e dello sviluppatore sul diff prima che inizi l'implementazione. Questa è spec-del-design-come-codice. MCP non ha equivalenti.

L'argomento del determinismo

Stessa versione del file Figma + stessa esportazione figmascope = stesso bundle. Ogni volta. Lo schema IR è fisso. La logica di sourcing dei token è deterministica. L'estrazione delle chiavi delle stringhe è basata su regole.

Il recupero MCP non è deterministico. L'agente decide cosa recuperare. Agenti diversi, formulazione del prompt diversa, budget di contesto diversi — comportamento di recupero diverso. L'output è dipendente dal modello.

Per la codegen di UI di produzione, il determinismo conta. Vuoi che la specifica che ha generato un componente sia riproducibile. Vuoi poter rigenerare il componente dagli stessi input e ottenere risultati consistenti. I bundle supportano questo. Le sessioni MCP no.

Confronto

Dimensione Figma MCP Bundle figmascope
Freschezza dei dati Sempre live — recupera stato Figma corrente Snapshot — aggiornato quanto l'ultima esportazione
Passaggio di esportazione richiesto No Sì — una volta per versione del design
Adatto a version control No — nessun artefatto Sì — bundle è JSON + Markdown confrontabile con diff
Persistente tra sessioni No — deve ri-recuperare ogni sessione Sì — i file persistono indefinitamente
Funziona offline No Sì
Output deterministico No — recupero dipendente dal modello Sì — stesso input → stesso bundle sempre
Pressione finestra di contesto Alta — il JSON grezzo di Figma è grande e non strutturato Bassa — l'IR è pre-elaborato, dimensione limitata
Operazioni di scrittura su Figma Sì (alcuni server MCP) No — esportazione in sola lettura
Spec design in cronologia git No Sì — committa il bundle, traccia la cronologia del design
Setup agente richiesto Sì — configura server MCP per client agente No — qualsiasi agente che legge file funziona
Chiavi stringa i18n Non nello schema MCP base di Figma Sì — stringRef.key nell'IR + strings.json
IR spaziale / layout Albero nodi Figma grezzo (nessun tipo di layout semantico) IR tipizzato: stack / overlay / absolute / leaf
Sourcing token Variabili se impostate; altrimenti valori grezzi Variabili → inferiti per frequenza → nessuno

MCP brilla per "modifica Figma live" — i bundle brillano per "costruire UI di produzione"

Questo è il riassunto onesto. Se il tuo flusso di lavoro è l'esplorazione conversazionale del design — "cambia questo componente," "annota questa schermata," "quali sono i token di colore su questo frame" — la connessione live di MCP è il modello giusto. L'agente è un collaboratore nel processo di design e ha bisogno di dati correnti per farlo.

Se il tuo flusso di lavoro è costruire UI di produzione da un design finalizzato (o quasi finalizzato) — implementare componenti, collegare lo stato, scrivere test — il modello bundle è migliore. Vuoi la specifica ancorata nel tuo repo, confrontabile con diff tra iterazioni del design, leggibile da qualsiasi agente senza configurazione e abbastanza deterministica su cui costruire.

I due modelli sono complementari. Usa MCP quando il design è in evoluzione e stai iterando in modo collaborativo. Esporta un bundle figmascope quando il design è stabile e lo stai consegnando agli ingegneri per l'implementazione. Il bundle diventa la fonte di verità su cui è costruita l'implementazione — tracciabile, revisionabile, riproducibile.