Skip to main content
Glama
deenesjakoruzh
Rachit0-glitch

Unified Figma MCP

by Rachit0-glitch
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Local

Unified Figma MCP

Unified Figma MCP coordinates Plumb-family and Custom-family Figma capabilities without modifying either original backend.

Correct local path:

C:\Users\rachi\OneDrive\Documents\FIGMA UNIFIED MCP

Stage 4 Status

Stage 4 turns the Stage 3.5 single-plugin proof of concept into a production Unified runtime foundation:

Unified MCP -> CapabilityRegistry -> CommandRouter -> ProtocolAdapter -> CommandQueue -> UnifiedBridge -> UnifiedPlugin -> Figma

Primary Stage 4 tools:

node scripts\unified-probe.mjs unified_capabilities
node scripts\unified-probe.mjs unified_execute '{"capability":"plumb.outline","payload":{}}'
node scripts\unified-probe.mjs unified_execute '{"capability":"custom.node.read","payload":{"depth":1}}'
npm run stage4:live

Supported production runtime capabilities:

  • plumb.status

  • plumb.outline

  • plumb.selection.read

  • custom.status

  • custom.node.read

  • custom.selection.read

All Stage 4 capabilities are read-only. Original Plumb and original Custom are not modified.

Stage 4 docs:

  • docs/STAGE4_POC_REVIEW.md

  • docs/STAGE4_ARCHITECTURE.md

  • docs/UNIFIED_PROTOCOL.md

  • docs/CAPABILITY_REGISTRY.md

  • docs/COMMAND_ROUTING.md

  • docs/RUNTIME_LIFECYCLE.md

  • docs/STAGE4_TEST_PLAN.md

  • docs/STAGE4_RESULTS.md

Related MCP server: Local Figma MCP Bridge

Block A Status

UNIFIED CAPABILITY INTEGRATION: PASS — see docs/BLOCK_A_FINAL_REPORT.md for the exact-format final report. Block A integrates the mature Plumb and Custom MCP capability surfaces into the one hardened Unified runtime, reusing real source-of-truth logic rather than reimplementing it (docs/BLOCK_A_INTEGRATION_ARCHITECTURE.md: reuse-by-import for pure Node logic — the actual figma-custom-mcp compiler/schema/diff/measure modules are a real dependency — vs. reuse-by-porting, verbatim, for Figma-plugin-sandbox code, which must physically run inside whichever one plugin is currently paired).

29 capabilities are registered (up from 6 at the start of Block A): full-fidelity reads, the complete create/update/delete/reorder write path, hierarchy/reparenting, components/instances/grouping, P2 advanced operations (masks, paint/text/effect/grid styles, component properties, variables), the complete P3 inspect→measure→diff→correct→verify→idempotency loop, and file-wide Plumb component extraction — every one real-Figma-verified, including a real local-image import (the exact P0 gap FIGMA/PLUMB_GAP_ANALYSIS.md documents Plumb as structurally incapable of), a 901-node large-tree stress test (after finding and fixing a real font-loading performance bug), and a one-continuous-session Plumb→Custom→P2→P3→Plumb full-system acceptance run (21/21, zero manual plugin switching, zero restarts, zero orphan responses). plumb.node.read/plumb.tokens are explicitly deferred with technical justification, not silently missing — see docs/BLOCK_A_SOURCE_PARITY.md. Full capability inventory: docs/BLOCK_A_CAPABILITY_MATRIX.md. Real-Figma test evidence: docs/BLOCK_A_LIVE_RESULTS.md.

Block B Status

Block B turns Block A's execution substrate into a production-hardened design execution engine — no new capabilities, no architecture changes, purely reliability/operability additions on top of the same one-plugin path. Adds: an operation model (operationRecord on every unified_execute response — operation id, retry-safety classification, status, payload fingerprint), a reconciliation decision engine (src/runtime/reconciliation.js) that recommends — never auto-performs — the safe retry action for an ambiguous failure, an execution planner reachable via a new unified_execute_plan tool (ordered steps, dependency ordering, checkpoints, resumability), two new error codes (INVALID_HIERARCHY, FONT_ERROR), connection-generation tracking for real plugin reconnects, and an iterative payload-shape guard closing a real stack-overflow vulnerability in recursive schema validation. The production tool set is now unified_capabilities, unified_execute, unified_execute_plan, unified_runtime_status (the 4 legacy diagnostic tools remain unchanged, still opt-in only).

Full detail: docs/BLOCK_B_ARCHITECTURE.md, docs/BLOCK_B_OPERATION_MODEL.md, docs/BLOCK_B_ROUTING_POLICY.md, docs/BLOCK_B_RETRY_RECONCILIATION.md, docs/BLOCK_B_BATCH_DECISION.md, docs/BLOCK_B_PERFORMANCE.md, docs/BLOCK_B_FAILURE_TESTS.md, docs/BLOCK_B_LIVE_RESULTS.md, docs/BLOCK_B_LIMITATIONS.md, docs/BLOCK_B_FINAL_REPORT.md.

Production Lock Status

SYSTEM PRODUCTION LOCK: PASS. A final hardening pass closing Block B's one remaining limitation and freezing the architecture ahead of Block C (not started). Adds pauseAtCheckpoint to unified_execute_plan — a deliberate, externally-observable mid-plan pause boundary — and uses it to prove, live, the full mid-flight interruption + resume chain: plan starts → pauses → plugin genuinely disconnects → a same-plan continuation attempt fails safely → plugin reconnects → the SAME session resumes → completes → verifies twice with zero corrective mutation (14/14, scripts/production-lock-interruption-live.mjs). Also proves the MCP-process-restart boundary explicitly (8/8, scripts/production-lock-process-restart-live.mjs): a paused plan survives a real server-process restart as long as the caller retained the returned run object — no disk persistence exists, stated honestly rather than assumed. Re-audited queue concurrency (no race can bypass CommandQueue's single-active-lane guarantee), capability registry metadata (found and fixed 3 missing timeoutMs fields), and source-system/dependency independence. 146/146 tests passing.

Full detail: docs/PRODUCTION_READINESS_FINAL.md (the complete current-state reference) and docs/PRODUCTION_BASELINE.md (the concise baseline record).

Pre-Block-A Hardening Status

UNIFIED MCP STATUS: READY FOR BLOCK A. Before Block A capability integration begins, this pass resolved 15 architectural/reliability issues (H1-H15) found by a read-only audit of the Stage 4 foundation: the old dual-plugin-runtime path is now gated behind an opt-in diagnostics flag and excluded from the default MCP tool set, the shallow custom.design.apply proof of concept was shelved (archived, not deleted), capability payloads are now validated by Zod schemas before any bridge call, the command queue is bounded with distinct QUEUE_FULL/QUEUE_WAIT_TIMEOUT errors, Unified now owns its own ws/zod dependencies instead of reaching into FIGMA-CUSTOM-MCP, and structured errors preserve their originating source and specific message end-to-end. All of it was verified live against the real Unified Runtime Figma plugin, not just unit tests. Full results: docs/HARDENING_RESULTS.md. Per-issue detail: docs/PRE_BLOCK_A_HARDENING.md. Test methods/evidence: docs/HARDENING_TEST_PLAN.md.

The production tool set is unchanged in shape (unified_capabilities, unified_execute, unified_runtime_status), but 4 legacy diagnostic tools (unified_status, unified_backends, unified_active_backend, unified_probe_backend — the old dual-runtime path) now require UNIFIED_ENABLE_LEGACY_DIAGNOSTICS=true on the server process's own environment to register at all. See docs/LEGACY_RUNTIME_POLICY.md.

Stage 1 Status

Stage 1 is documentation and verification only. The repo currently contains architecture docs, test results, and a Custom MCP SDK probe. No production coordinator implementation has been added yet.

Key Finding

Plumb and Custom both work as real Figma MCP paths, but the current Figma workflow supports one active MCP plugin bridge at a time. Unified MCP should therefore expose explicit backend health and clear switch prompts.

Docs

  • docs/CURRENT_SYSTEM.md

  • docs/PLUMB_ARCHITECTURE.md

  • docs/CUSTOM_MCP_ARCHITECTURE.md

  • docs/PROTOCOL_MAP.md

  • docs/CAPABILITY_MATRIX.md

  • docs/ARCHITECTURE_OPTIONS.md

  • docs/FAILURE_ANALYSIS.md

  • docs/IMPLEMENTATION_RECOMMENDATION.md

  • docs/TEST_PLAN.md

  • docs/STAGE1_RESULTS.md

Diagnostic Script

scripts/custom-mcp-sdk-probe.mjs

Example:

node scripts\custom-mcp-sdk-probe.mjs --wait-paired --read --write

The script starts the existing Custom MCP server as a child process, talks MCP over stdio using the MCP SDK installed in FIGMA-CUSTOM-MCP, and optionally verifies status, read, write, and cleanup.

Stage 2 Status

Stage 2 adds the first real Unified MCP coordinator runtime:

npm run start

Diagnostic helpers (legacy, opt-in-gated — see Pre-Block-A Hardening Status above; unified-probe.mjs auto-passes UNIFIED_ENABLE_LEGACY_DIAGNOSTICS=true when the tool name is one of these 4):

node scripts\unified-probe.mjs unified_status
node scripts\unified-probe.mjs unified_probe_backend '{"backend":"plumb"}'
node scripts\unified-probe.mjs unified_probe_backend '{"backend":"custom"}'
node scripts\unified-live-sequence.mjs

Stage 2 docs:

  • docs/STAGE2_ARCHITECTURE.md

  • docs/STAGE2_TEST_PLAN.md

  • docs/STAGE2_RESULTS.md

  • docs/BACKEND_ADAPTERS.md

  • docs/STATUS_MODEL.md

  • docs/ERROR_MODEL.md

Stage 3 Status

Stage 3 investigated automated backend handoff. Result: AUTOMATED HANDOFF BLOCKED under the current two-plugin architecture. Unified MCP can observe manual backend changes, but it cannot legitimately launch the inactive Figma plugin without a new plugin architecture or fragile UI automation.

Stage 3 docs:

  • docs/STAGE3_INVESTIGATION.md

  • docs/HANDOFF_STATE_MACHINE.md

  • docs/BACKEND_LIFECYCLE.md

  • docs/STAGE3_TEST_PLAN.md

  • docs/STAGE3_RESULTS.md

  • docs/HANDOFF_BLOCKER.md

  • docs/RUNTIME_ALTERNATIVES.md

Available Tools

4 tools
unified_active_backendA

Return only the currently detected active Figma backend.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations to rely on, so the description must carry the burden of behavioral transparency. It only states the return action without disclosing potential side effects, error handling, or whether the tool is read-only. This minimal disclosure leaves ambiguity about edge cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that conveys the essential information without superfluous content. It is well-structured and directly to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool and the absence of parameters or output schema, the description is largely complete. However, it does not clarify what constitutes 'active' or 'detected', which might be relevant for a user to fully understand the tool's behavior in ambiguous scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool accepts no parameters, so there is nothing to explain. The description correctly does not mention any inputs, and the schema confirms zero parameters, making this dimension trivially satisfied.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states that the tool returns the currently active detected Figma backend, which is a clear and specific purpose. It distinguishes this tool from potential alternatives by focusing on the active backend only.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidelines are provided. The description does not indicate when to use this tool versus the sibling tools (unified_status, unified_backends, unified_probe_backend), nor does it mention any conditions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

unified_backendsB

Return known Unified MCP backends and their capability summaries.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of disclosing behavior. It says it returns backends and capability summaries, but it doesn't specify what 'known' means (e.g., static list, dynamic discovery), whether it involves network calls, or what the output structure is. It is not misleading, but it is under-transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one sentence, front-loaded, and wastes no words. It achieves conciseness without under-specification (though room remains for more detail).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters, no output schema, and no annotations, the description gives a high-level purpose but lacks details like the format of 'capability summaries' or whether the result is a list or map. It is adequate for simple discovery but leaves meaningful questions for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0 parameters, there is no additional meaning to provide. The baseline for no parameters is 4, and the description appropriately focuses on the purpose. It exceeds because it clarifies the output includes capability summaries, which is useful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool returns known backends and their capabilities, which is clear and specific. It could be improved by distinguishing it from sibling tools like 'unified_status' or 'unified_active_backend', but it stands on its own.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for discovering backends, but does not explicitly state when to use it versus alternatives. Sibling tools exist for status and active backend, but no guidance is given on when to prefer this one.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

unified_probe_backendA

Run a safe read-only diagnostic through one backend: plumb or custom.

ParametersJSON Schema
NameRequiredDescriptionDefault
backendYes

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

States the operation is safe and read-only, but no details on what the diagnostic entails, potential results, or side effects. Since no annotations exist, the description carries the full burden and is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise and to the point. Includes essential information (safe, read-only, backend choices) without redundancy or unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and annotations, the description lacks details about what the diagnostic returns or accomplishes. It's vague about the nature of the probe, leaving the agent uncertain about outcomes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'backend' is well-defined via enum and required, providing full schema coverage. The description adds minimal value beyond restating the options, so it meets the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool runs a safe read-only diagnostic and specifies the backend options (plumb or custom). Distinguishes from sibling tools like unified_status or unified_backends by focusing on probing a backend.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a hint of usage ('diagnostic', 'safe read-only') but lacks explicit guidance on when to choose this tool over alternatives. No mention of conditions or context for probing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

unified_statusB

Return current normalized health for Plumb and Custom backends plus active backend detection.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only health status operation but does not explain what 'normalized' means, whether probing occurs, what counts as active, or any side effects or data-access implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It efficiently conveys the core action and scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is no output schema, no annotations, and several closely related sibling tools, the description is too thin. It does not explain the meaning of 'normalized health', what 'active backend detection' entails, or how this endpoint differs from unified_active_backend.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to add about parameters. The baseline of 4 is appropriate here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb ('Return') and specifies a resource ('current normalized health for Plumb and Custom backends plus active backend detection'), which conveys the core purpose. However, it does not explicitly distinguish itself from the sibling tool unified_active_backend, which likely also covers active backend detection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus siblings such as unified_backends, unified_active_backend, or unified_probe_backend. There is no context about scenarios, exclusions, or preferred alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 4 tool updatesv0.1.0
    • First observedunified_active_backend
    • First observedunified_backends
    • First observedunified_probe_backend
    • First observedunified_status
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation2/5

unified_status and unified_active_backend clearly overlap—both report active backend detection, making one redundant. unified_backends and unified_probe_backend are more distinct, but boundaries between status, backends, and probing are not crisp, causing potential misselection.

Naming Consistency4/5

All tools share the 'unified_' prefix and use snake_case, creating a predictable pattern. Minor inconsistency exists because three are noun-based (status, backends, active_backend) while probe_backend is verb+noun, but overall naming remains coherent and easily scannable.

Tool Count4/5

Four tools is within the ideal range for a focused server, but the overlap between status and active_backend reduces efficiency. Still, the count is not excessive and each tool has a named purpose, even if some purposes are redundant.

Completeness4/5

The server appears scoped to backend status and diagnostic coverage; it includes health normalization, capability listing, active detection, and probing. It lacks operations like switching backends or configuration, but for a read-only status server, coverage is largely sufficient.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Local Figma MCP Bridge

    ikoba0911
    A
    license
    Not graded
    quality
    C
    maintenance
    Unofficial local MCP bridge for reading the currently open Figma file through a Figma plugin. Provides tools to inspect selection, file info, and export selected nodes as SVG/PNG.
    MIT

  • pholly-figma-mcp

    mubzie
    A
    license
    Not graded
    quality
    B
    maintenance
    Local-first MCP bridge for live Figma documents, enabling design inspection, editing, asset export, component authoring, and variable management through a plugin and WebSocket server without consuming Figma REST API requests.
    1
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Rachit0-glitch/UNIFIED-CUTOSM-FIGMA-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server