Vibma: an MCP bridge that let AI agents write auto-layout into Figma, now archived by Figma's own agent tools

The problem Vibma targeted: LLM output that looks like a mockup but is not a Figma file

An agent that can call a design API can place rectangles. What it usually cannot do is produce a file a designer would accept, because the difference between a screenshot-shaped arrangement and a working Figma document sits in the structure: auto-layout instead of absolute positioning, tokens instead of hardcoded hex values, components instead of duplicated groups. Vibma's README states the goal in exactly those terms, saying it helps agents produce "structurally sound Figma files" with proper auto-layout, design tokens, component architecture and reusable design-system patterns. The audience is therefore narrow and specific. It is not for someone who wants an image of a UI. It is for teams whose agents write into a shared Figma library and whose downstream handoff depends on the file remaining editable, responsive and consistent with an existing token set. If your workflow ends at a rendered picture, the extra structure buys you nothing.

How the bridge is wired: an MCP server, a Figma plugin, and a model in the middle

The architecture implied by the repository is a three-part chain. An MCP-capable LLM client connects to the Vibma server, which exposes Figma operations as MCP tools with typed parameters and response schemas. Those calls are relayed into a Figma plugin running inside the desktop app, which performs the actual document mutations. The README credits cursor-talk-to-figma-mcp by sonnylazuardi as the base, so the transport pattern is inherited rather than invented here. Two optional integrations sit alongside the core tool set. Setting FIGMA_API_TOKEN plus FIGMA_TEAM_ID turns on a Library capability that discovers published team library components and styles, and setting PEXELS_API_KEY turns on an Images capability that searches and places stock photos. Icon search and insertion is handled through the Iconify public API, which the README describes as a unified framework covering 200,000+ icons across 100+ collections. The documentation lives at a separate GitHub Pages site and is described as a tool reference with parameters, response schemas and examples, which is where you would go to learn the exact call surface.

Two setup paths, and the paste-this-to-your-agent shortcut

The README offers three routes. DRAGME.md covers cloning the repository and building from source. CARRYME.md covers installing from npm with no clone. The third is a prompt you hand to an agent: it instructs the agent to follow the instructions at a raw CARRYME.md URL on the main branch. That third option is the honest expression of who this is for, since it assumes the reader has an agent capable of fetching a URL and executing setup steps, and it assumes the reader would rather not read the steps. All core tools are stated to work without API keys, so the two environment variables are genuinely optional. If you do enable the Library tool, the README specifies that the Figma personal access token needs two scopes: File content (Read) and Team library content (Read). A token missing either scope will produce a partial failure rather than an obvious one, since the other tools keep working.

Model choice is treated as a first-class variable, which tells you where the failure actually lives

Vibma's README carries a model recommendation table with a Baseline and a Recommended tier across OpenAI, Claude, Gemini and open-source options. The notes are unusually blunt. GPT 5.4 is called the best overall balance of tool competence and design taste. Claude Opus 4.6 is credited with the strongest tool use while its final designs are described as sometimes formulaic. Gemini 3.1 Pro is called a solid middle ground that GPT 5.4 currently edges on both axes. Kimi K2.6 is noted for following harness instructions well. The framing is a concession. If the tool layer were deterministic, model choice would matter far less than it evidently does here. The quality of the resulting Figma file depends on the model's judgement about layout and hierarchy, not just on whether it can call the right function with valid arguments. That is a real limitation, and the project names it rather than hiding it.

The project is discontinued, and the reason is the most important fact about it

The status notice is unambiguous. Vibma is no longer under active development. Figma launched native MCP capabilities through a product called Figma for Agents, and the Vibma plugin was not accepted to the Figma marketplace due to what the notice quotes as "overlap" with that first-party offering. The README also states plainly that Vibma is not an official Figma tool and points production users to Figma's native MCP integration. The source remains available under MIT for learning and reference. This changes the evaluation entirely. You are not comparing two live tools. You are looking at a working design that a platform vendor absorbed into the platform itself, which is a common and predictable end state for plugins that extend a closed product's core workflow. The marketplace rejection is the practical blocker: even if you build from source, distribution through the normal channel is closed.

The alternative is the thing that displaced it, and the difference is in who owns the schema

Figma for Agents is the named alternative, and the distinction is architectural rather than cosmetic. Vibma is a third-party MCP server that translates tool calls into plugin actions against Figma's plugin API, which means it lives downstream of whatever that API exposes and depends on the plugin being installed and permitted. Figma's native MCP support is first-party, so the tool schema, the authentication model and the update cadence come from the same vendor that ships the editor. The practical consequence is that a first-party integration does not break when a plugin sandbox changes, and it does not need to be reinstalled after a Figma release. The cost is the usual one: you take the vendor's tool surface as given, and you cannot fork it when a parameter is missing. Vibma's MIT licence meant anyone could read and modify the bridge, which is exactly what the maintainers now suggest doing with it.

Maintenance, licensing and what the MIT grant does not cover

The repository is not archived, the last push recorded is 2026-06-08, and the most recent release listed is v1.1.5 from 2026-05-19, preceded by a release candidate two days earlier and v1.1.3 on 2026-04-19. So the code received attention after the discontinuation notice appeared, but the README gives no commitment to future patches, and the stated position is that development has stopped. The MIT licence covers the Vibma source, and that grant is unaffected by the project's status. It does not cover the surrounding dependencies. The README directs readers to the Pexels Terms of Service and asks that photographers be credited in production, and it recommends reading Figma's Terms of Service before using Vibma to ensure compliance with their platform policies. That last point is the one to take seriously: a plugin that was rejected from the marketplace for overlapping a first-party feature is a poor candidate for a workflow that a legal or platform-compliance reviewer will examine. This is not legal advice, and the licence text plus the two third-party terms are the documents that actually govern your use.

Who should still open this repository

The useful audience is engineers building their own Figma agent bridge. Vibma's value now is as a readable TypeScript reference for how auto-layout, tokens and component construction were mapped onto MCP tool schemas, and the docs site still describes the parameter and response shapes. Anyone doing that work should read the tool reference first, then trace how the Library tool consumes FIGMA_API_TOKEN and FIGMA_TEAM_ID, because the two-scope requirement is a detail that is easy to get wrong and produces silent partial failures. Design teams should not start here. The plugin is not in the marketplace, the maintainers have stopped work, and they point to Figma directly. Verify the plugin install path before investing any time, and check whether the native integration already covers your node types. The repository's own notice answers the adoption question before you open the code.

Editorial conclusion

Adopt Vibma only as a reference implementation: read the tool schemas and the auto-layout logic if you are building your own Figma MCP bridge, and check the repository's LICENSE and the Figma Terms of Service before any commercial deployment, because the README itself flags platform compliance as the user's responsibility. Do not adopt it for production design work, since the project is no longer under active development and the maintainers point to Figma for Agents instead. Verify first whether Figma's native MCP integration covers the specific node types you need, and confirm the plugin install path still works at all, given the marketplace rejection.

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. ufira-ai/Vibma on GitHub