Figma Codex Bridge

by xiaobai59

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Each tool targets a distinct aspect: status, metadata, page structure, selection, node, context, screenshot. Some overlap exists between get_selection and get_node, but ID-based vs current selection keeps boundaries clear.
Naming Consistency4/5
All tools share the figma_ prefix and most use the get_ verb, but figma_status breaks the verb_noun pattern. The naming remains predictable and readable overall.
Tool Count5/5
Seven tools is well-scoped for a design-to-code bridge, covering status, metadata, page structure, selection, node access, context packing, and screenshots without unnecessary bloat.
Completeness5/5
The set covers all read-oriented needs for extracting design context: file info, page hierarchy, node access, selection, comprehensive context with tokens/styles/assets, and screenshots. No obvious gaps for a read-only bridge.
Average 3.6/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on August 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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 for behavioral disclosure. It only states that the operation is a read and that it defaults to the current page. It does not disclose behavior regarding depth limits, node limits, or the structure/shape of the returned data.
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 extremely concise, only two short sentences, and the primary verb/resource is front-loaded. Every word earns its place, though the conciseness comes at the expense of necessary detail.
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 should explain more about expected return values and parameter effects, but it does not. Although the default current-page behavior is mentioned, the tool is not complete enough for an agent to understand the full impact of the other parameters or interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only pageId has a description), but the tool description adds no additional meaning for depth, maxNodes, or maxChildren. It merely reinforces the pageId default, leaving the other three parameters without useful clarification.
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 clearly states the action ('Read') and the resource ('top-level nodes on a Figma page'), making it specific and distinguishable from sibling tools like figma_get_node or figma_get_selection. The addition 'Defaults to the current page' further clarifies scope.
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?
No guidance is given on when to use this tool versus alternatives such as figma_get_selection or figma_get_node. The only contextual hint is that it defaults to the current page, but there is no explicit when-to-use or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without any annotations, the description carries the burden of disclosing behavioral traits. It clearly indicates a read operation ('Read') and hints at limits via 'bounded child tree', but it does not explain what the bounds are, how limits are enforced, or any error behavior. This is minimal but not misleading.
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 front-loads the core action and resource. Every word earns its place, with no redundant or extraneous information.
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?
For a tool with four parameters and no output schema or annotations, the description is too brief to be fully complete. It explains the basic purpose and that the tree is bounded, but it omits how the bounds are controlled and what the tool returns in specific scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only nodeId is described). The description adds only a general notion of 'bounded child tree', which relates to the depth, maxNodes, and maxChildren parameters, but it does not explain their individual meanings or defaults. This is insufficient compensation for the low schema coverage.
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 uses the specific verb 'Read' and clearly identifies the resource as 'one Figma node by ID', which distinguishes it from sibling tools that work with selections or whole files. The phrase 'including its bounded child tree' further specifies the scope of the operation.
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 gives no explicit guidance on when to use this tool versus alternatives. It only states what it does, without mentioning that it should be used when a specific node ID is known, nor does it reference any sibling tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does indicate 'Read', implying a non-mutating operation, and lists some output content, but it does not disclose important behavioral traits such as what happens with an empty selection, the meaning of 'bounded child tree', or performance implications. The description is too sparse for full behavioral transparency.
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, direct sentence that front-loads the core function ('Read the current Figma selection') and includes no redundant or unrelated information. It earns every word.
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?
With no output schema and no annotations, the description needs to be more self-sufficient. It states the basic action and some output categories but does not explain the result format, how the parameters shape the output, or edge cases. For a simple tool this is still a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters (depth, maxNodes, maxChildren) are only known by name and constraints. The description's phrase 'bounded child tree' hints that parameters control limits, but it does not explain each parameter's meaning or effect. The compensation is minimal and leaves the agent to guess from names and defaults.
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 uses the specific verb 'Read' and names the resource 'current Figma selection', while listing key output categories (layout, text, fills, bounded child tree). This clearly distinguishes it from sibling tools like figma_get_node (specific node) and figma_get_screenshot (image).
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 context is clear: it reads the current selection. However, there is no explicit guidance on when to use this tool versus alternatives, no exclusions, and no mention of when not to use it. The usage is implied by the name and description, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool aggregates data (read operation) and mentions 'bounded structure', hinting at output limiting. However, it doesn't cover permissions, error handling, rate limits, or performance implications, leaving behavioral transparency incomplete.
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 sentence, front-loaded with the core purpose, followed by a compact list of included content. Every phrase adds necessary information with no wasted words.
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?
The description gives a clear overall purpose but lacks details on return structure, parameter behavior, or caveats. Given the absence of an output schema and six parameters, the description is adequate but not thorough, leaving an agent to infer important usage details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only nodeId has a schema description (17% coverage). The description hints at depth/maxNodes/maxChildren via 'bounded structure' and includeScreenshot via 'optional screenshot', but does not define scale or clarify the relationship between depth and maxChildren. This partial compensation is insufficient given the low schema coverage.
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 clearly states the tool builds an implementation-ready context pack from a selection or node, listing specific content types (tokens, components, variables, styles, assets, screenshot). This distinctly differentiates it from sibling get_* tools that each return a narrower slice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies it is for generating a comprehensive context pack, implying when to use this over simpler getters. It provides clear context but does not explicitly name alternatives or provide when-not-to-use guidance, though the 'implementation-ready' framing is informative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It states the tool exports a PNG image, but doesn't mention behavior with no selection/nodeId, scale constraints, or potential errors. It adds minimal context beyond the schema.
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 front-loads the primary action and object, with no redundant wording or filler.
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?
The tool is simple with two optional parameters and no output schema. The description covers the main purpose and nodeId semantics. It could improve by mentioning what happens if neither selection nor nodeId is available, but overall it's adequate for its complexity.
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?
Schema description coverage is 50% (nodeId is described, scale is not). The description clarifies that nodeId defaults to the current selection ('current selection or a Figma node'), adding meaning to that parameter. However, scale is not mentioned or explained.
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 uses a specific verb ('Export') and clearly identifies the resource ('the current selection or a Figma node as a PNG image'). It distinguishes itself from sibling get-style tools by focusing on image export rather than data retrieval.
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 phrase 'for visual comparison' implies a use case, but there is no explicit guidance on when to use this tool versus alternatives or when not to use it. Sibling tools are all read-only getters, making this the clear export option, but the description doesn't emphasize that distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior. It indicates a read operation ('Read'), implying non-destructiveness, and notes the dependency on the current file in Figma Desktop. However, it does not describe failure modes (e.g., no file open) or what metadata specifically is returned.
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 is front-loaded with the action 'Read metadata' and includes the essential context. There is no wasted wording.
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?
For a zero-parameter, no-output-schema, read-only tool, the description gives the essential purpose and context. It is vague about what 'metadata' encompasses, but given the low complexity and sibling tools covering specific aspects, it is reasonably complete.
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, so there is no parameter information needed. The description adds contextual meaning about the implicit input (the current file), but since the schema is empty, the description is sufficient and the baseline of 4 applies.
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 uses a specific verb ('Read') and identifies the resource ('metadata for the Figma file currently open in Figma Desktop'), which clearly differentiates it from sibling tools focusing on page structure, selection, nodes, or screenshots.
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 the tool is for retrieving metadata about the current file but provides no explicit guidance on when to use it over alternatives or when not to use it. The context of 'currently open in Figma Desktop' gives some situational clarity, but sibling comparisons are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. The verbs 'check' and 'report' imply a read-only, non-mutating operation, but the description does not disclose potential failure modes (e.g., what happens if the plugin is not connected) or any side effects. It adds minimal context beyond what the verbs convey.
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 that states the tool's purpose without any extraneous words. It earns its place completely.
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?
For a simple status check with no parameters and no output schema, the description covers the core purpose and main outputs. It omits details about the reporting format or connection semantics, but the tool's simplicity makes this acceptable.
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 zero parameters, the schema fully defines the input structure. The description adds no parameter details, but none are needed. The baseline for zero parameters is 4, and the description does not detract from this.
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 uses specific verbs 'check' and 'report' with clear targets: the local Figma Desktop plugin connection and the active file/page. This clearly distinguishes it from sibling tools that fetch metadata, page structure, selection, nodes, design context, or screenshots.
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 the tool is for status checks but provides no explicit guidance on when to use it over siblings or when not to use it. It does not mention alternatives or exclusions, leaving the agent to infer usage from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![figma-codex-bridge MCP server](https://glama.ai/mcp/servers/xiaobai59/figma-codex-bridge/badges/card.svg)](https://glama.ai/mcp/servers/xiaobai59/figma-codex-bridge)

Score Badge

Copy to your README.md:

[![figma-codex-bridge MCP server](https://glama.ai/mcp/servers/xiaobai59/figma-codex-bridge/badges/score.svg)](https://glama.ai/mcp/servers/xiaobai59/figma-codex-bridge)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/xiaobai59/figma-codex-bridge'

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