figma-bridge-mcp
Server Quality Checklist
Latest release: v0.6.1
- Disambiguation3/5
Most tools are distinct, but figma_inspect and figma_spec both target node/layer facts, and figma_connect, figma_status, and figma_pairing all relate to setup/connection. The descriptions provide enough detail to choose correctly in most cases, but the boundaries are not fully crisp.
Naming Consistency3/5All tools share the figma_ prefix and snake_case, but the suffix pattern is mixed: connect, run, render, and inspect are actions, while status, pairing, comments, history, and spec are nouns. The convention is readable and consistent in prefix, but not consistently verb_noun.
Tool Count4/5Twelve tools is a reasonable size for a Figma bridge covering setup, rendering, inspection, comments, screenshots, and history. Some tools overlap slightly and could be consolidated, but the count is neither excessive nor too thin.
Completeness4/5The surface covers connection/setup, status, rendering, selection, comments, node inspection, specs, screenshots, history, and an offline reference. Minor gaps like comment update/delete or explicit file-scoped operations exist, but core workflows appear supported.
Average 3.4/5 across 12 of 12 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 422 commits in the last 12 weeks
- Last stable release on
- 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.jsonto 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?
Annotations already indicate readOnlyHint=false and openWorldHint=true, so the description adds no new behavioral insight. It does not explain side-effects, scope of mutation, reversibility, or the confirm/preview flow. Given the open-world hint, more disclosure would be expected, but the description stays silent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise and free of filler, but it lacks structure and does not front-load critical information like the required confirm parameter or the preview mode. It is appropriately short but at the cost of essential detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 21 parameters, no output schema, and low schema coverage, the description is severely incomplete. It fails to explain the difference between jsx and roots, the meaning of most parameters, or the behavioral implications. An agent would be guessing at almost every operational aspect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 19%, so the description must compensate, but it only mentions jsx and roots as primary inputs. The remaining 19 parameters (x, y, gap, preset, verify, confirm, etc.) are left unexplained. The description adds only marginal meaning beyond the schema, far from sufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (render), the inputs (JSX or roots[] batch), and the target (Figma). It distinguishes between two input modes, giving a specific verb-resource pair. However, it does not explicitly differentiate it from sibling tools like figma_run or figma_screenshot, so it misses the distinguishing context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of alternatives, conditions, or exclusions. The description simply declares what the tool does without any contextual routing, leaving an agent without criteria for tool selection.
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?
Annotations are present: readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds that it may 'recover', 'create its key', or 'show setup', suggesting a setup/recovery operation with possible side effects (creating a key). While it doesn't conflict with annotations, it doesn't clearly describe side effects or what 'connect Safe Mode' entails; openWorldHint=true is consistent but vague. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main verb. However, the semicolon list of three actions is somewhat compressed and could be more explicit, but it is not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is an action-y tool with zero parameters, the description is too vague about what 'Connect Safe Mode' actually does, what the outcomes are, and how it differs from figma_pairing/figma_status. An agent would not know what to expect after calling it. The output schema is missing, which increases the need for behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description carries no parameter burden. Baseline for 0 params is 4. The description's ambiguity about actions is not necessarily about parameters, so this score is fair.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Connect') and resource ('Safe Mode'), and mentions three possible actions: recover the plugin, create its key, or show setup. However, it is ambiguous what 'connect safe mode' actually means and which of these actions will occur on invocation. It distinguishes a bit from siblings like figma_pairing and figma_status, but not clearly enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like figma_pairing or figma_status. The description implies it is for a setup/recovery scenario, but it doesn't state conditions, prerequisites, or when to prefer another sibling.
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?
Annotations already declare the operation as read-only, non-destructive, and open-world. The description adds that it performs a round-trip status check and can validate a REST token, which is useful, but it does not clarify what 'write policy' means or how the optional REST check behaves when skipped.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, scannable, and front-loaded with scope and purpose. It loses a point because the telegraphic fragment style creates mild ambiguity, for example whether 'Figma Bridge only' is an API restriction or a domain qualifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what a successful status response contains or what a negative result means, but it does not. It also leaves 'write policy' and 'round-trip' behavior underspecified, so an agent can select the tool but not confidently interpret its result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already documents fileKey, probePlugin, and validateRest clearly. The description's high-level status/REST phrasing maps to those parameters but adds no additional semantic detail beyond what the input schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (Figma Bridge) and the three relevant facets: round-trip status, write policy, and optional REST check. It is not a tautology, though it lacks an explicit verb and does not name a sibling tool for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no mention of alternative tools such as figma_connect or figma_pairing. The phrase 'Figma Bridge only' restricts scope but does not help an agent decide when this status tool is the right choice.
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?
The annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them; 'save/read' reinforces a read-oriented behavior. However, the description adds little beyond that—no detail about output format, persistence, caching, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loads the key directive 'MANDATORY,' making it efficient to parse. However, the terseness sacrifices a clear purpose statement and leaves much to inference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and many sibling tools, the description is incomplete: it does not explain what the PNG contains, how it is returned or saved, how optional parameters interact with the current-selection fallback, or what 'comparing the build' means. An agent would need additional context to invoke this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so scale, nodeId, and fileKey are already fully documented. The tool description adds no extra parameter semantics or usage nuances beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a resource (node PNG) and an action (save/read), but it reads as a workflow command—'MANDATORY: save/read the node PNG before comparing the build'—rather than a clear statement of tool function. It does not explicitly say that the tool captures a screenshot of a Figma node, and it does not distinguish itself from sibling tools like figma_render.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit temporal condition: this tool is mandatory before comparing the build. This gives clear context for when to invoke it, though it does not mention when not to use it or how it compares to alternative tools.
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?
Annotations already flag this as destructive (destructiveHint: true), and the description adds no behavioral nuance beyond 'approved.' It does not mention preview mode, the policy-required confirm flag, mutations, or consequences, so the description contributes little beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence states the core behavior and immediately directs the agent to the authoritative capability reference. There is no filler or redundant restatement of schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The pointer to figma_reference and --help gives an agent a discovery path, and the schema covers most parameters, but the description alone leaves key operating context unclear: what commands exist, how approval is determined, and what preview/confirm semantics mean operationally. Given the destructive hint and lack of an output schema, more context would improve call correctness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, so the parameters are mostly self-documenting; the description itself adds no parameter-level detail. Per the high-coverage baseline, a 3 is appropriate rather than a lower score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Run an approved command') and distinguishes this as the executor tool while pointing to figma_reference for allowed commands. It is not a tautology, but the command space itself is left unspecified until the agent consults the reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction to see figma_reference {name:'capabilities'} or --help implies how to identify approved commands, and the word 'approved' imposes a usage constraint. However, it does not explicitly state when to prefer this tool over sibling tools or what conditions disqualify a command.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/openWorld/non-destructive, and the description adds useful behavior: 'private' scopes the history and 'payloads omitted' discloses a response constraint. It does not detail auth/rate limits or the optional REST merge, but with annotations present this is a reasonable level of disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Twelve words with no filler; the opening 'Private command history' sets scope immediately and the trailing 'payloads omitted' is a high-value boundary. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite rich schema and annotations, this is an 8-parameter multi-mode tool with no output schema, and the description gives no mode-selection logic between diff, fileKey/includeVersions, and gitPaths/repoPath. It also does not clarify what 'private' entails or what the output shape looks like beyond payloads being omitted, leaving the agent to infer the intended workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies; to/from defaults, nodeId, fileKey, gitPaths, repoPath, format, limit, and includeVersions are already explained in the schema. The description's mention of versions and diffs maps to those parameters but adds no parameter-level detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names concrete resources—private command history, git/Figma versions, and snapshot diff—so an agent understands what domain the tool addresses. It lacks an explicit verb like 'retrieves' or 'lists' and does not name a sibling, but the resource set is specific enough to separate figma_history from figma_screenshot, figma_comments, and similar siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No sentence explains when to use this tool or when to prefer one of its sibling tools. The capability list implies a history/diff use case, but there is no exclusion guidance or alternative routing, which is important given 11 sibling tools.
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?
Annotations already mark the tool as readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the 'Offline' trait and the content scope, which gives some behavioral context, but it doesn't disclose specifics like list behavior on omitted name or return content format. Given annotation coverage, this meets a baseline without adding much beyond it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that leads with the core identity ('Offline API reference') and enumerates topics without filler. It is appropriately small and front-loaded, with no redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter, read-only reference tool with no output schema, the description names the resource and its topic areas, and the schema covers invocation details. It lacks explicit instruction that omitting name lists all entries, but that is already in the schema; the main gap is unclear differentiation from sibling tools, which is more a usage-guideline issue. Overall it is sufficient for the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is fully documented in the schema with 'API name or special topic; omit to list names.' The description contributes no additional parameter semantics beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as an 'Offline API reference' and lists the domains it covers (capabilities, fidelity, variable scopes, workflows), which signals a lookup/reference function. However, it lacks an explicit verb like 'query' or 'look up,' and it does not differentiate itself from siblings like figma_spec or figma_inspect, so an agent must infer the action from the noun.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 instead of alternatives such as figma_spec or figma_inspect. The term 'Offline' hints at a network-independent use case, but no explicit when/when-not conditions or alternative tool references appear.
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?
Annotations already indicate this is read-only and non-destructive, so the description does not contradict them. It adds the notion that the tool depends on a 'current' selection state, but does not disclose what happens when there is no active selection or whether the returned id is a node id. This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler or redundant phrasing. The purpose and output are stated directly, making it efficiently scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one optional parameter, full schema coverage, and safety annotations, the description is nearly complete. It conveys that the tool returns a reusable id, though it could mention behavior for an empty selection or confirm the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the fileKey parameter is already described as 'Figma key/URL.' The description adds no additional parameter-level meaning, which is consistent with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Read') and a specific resource ('the current Figma selection'), and indicates the output ('its id'). It distinguishes itself from rendering/screenshot/comment tools, though it does not explicitly name any sibling to differentiate from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives like figma_inspect or figma_reference, nor any mention of prerequisites such as an active Figma session or a non-empty selection. The usage is only implied by the verb 'Read' and the notion of a 'current selection'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful beyond-annotation behavior: a 'never invent' no-hallucination promise and batching behind a single approval. It does not mention output shape or errors, but the read-only nature is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is two short sentences with zero filler. It front-loads the core promise ('Exact layer facts; never invent') and follows with a specific, actionable batching note. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool: 9 optional parameters, anyOf constraints, no output schema, and 11 sibling tools. Two brief sentences do not provide enough context for an agent to understand what 'spec' returns, how nodeId and nodeIds interact, or when to pick this over figma_inspect/reference. The schema fully covers parameter syntax, but not tool selection or output expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the 9 parameters are already fully documented in the input schema. The description adds a small extra semantic around nodeIds — that batching 8 reads happens behind one approval — but it does not compensate for or clarify the other parameters, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Exact layer facts' clearly identifies the resource (layers) and the nature of the output (facts, not guesses), while 'never invent' signals a fidelity guarantee. It does not use an explicit verb like 'get' or 'return', and it does not explicitly distinguish itself from figma_inspect or figma_reference, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The line 'nodeIds[] batches 8 reads behind one approval' gives actionable guidance to batch multiple reads for efficiency, which is genuinely useful. However, it never says when to choose figma_spec over sibling tools or when not to use it, so the guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral information beyond the annotations: all post/reply calls preview and require confirm:true, and a missing token returns setup. The annotations only indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the confirmation and auth details are valuable additions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the purpose and critical confirm behavior. Both sentences earn their place, though 'REST comments' is slightly cryptic and the semicolon-heavy first sentence could be clearer as a full phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers parameters well and the description adds critical behavioral details, but with no output schema the return values are not described: no mention of what list returns, what a preview response looks like, or pagination. For an 8-parameter tool with multiple modes, this leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all eight parameters. The description mentions confirm:true, but the schema already explains the preview and confirmation flow; no additional parameter semantics are provided. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (comments) and the core actions: list feedback, and post/reply with preview behavior. It is clear enough to distinguish this from sibling tools like figma_inspect or figma_spec, though 'REST comments' is a bit terse and doesn't explicitly say 'Figma file comments'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives practical usage context: listing is the default action, while posting/reply always goes through a preview and requires confirm:true. It also notes the missing-token setup response. It does not explicitly compare to alternatives, but no sibling tool appears to handle comments, so this is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly discloses the destructive behavior: rotate:true replaces the key and restarts the daemon. This aligns with destructiveHint=true and adds specific context about what is affected, which goes beyond the annotation alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single semicolon-separated sentence with no filler. It front-loads the main purpose and then introduces the optional variant, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the core behavior and the destructive branch sufficiently. It omits return-value details and usage prerequisites, but these are minor given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the rotate parameter, but the description adds the default behavior of simply showing the key when rotate is not true. This clarifies the optional nature of the parameter and the outcome of the default call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary action ('Show the plugin key') and the optional destructive variant ('rotate:true replaces it and restarts the daemon'). This distinguishes figma_pairing from its siblings by specifying a unique resource and 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use figma_pairing versus its siblings, nor when rotation is appropriate or what prerequisites exist. The only condition mentioned is the rotate flag, but not the context that should trigger it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context by specifying the output as YAML and enumerating the fact categories covered. It does not contradict the annotations, though it omits details about failure modes or file resolution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. It front-loads the action and resource, then states the output format, earning full credit for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only inspection tool, the description is adequate: it names the output format, the fact categories, and the schema documents parameters. There is no output schema, but the description partially compensates by indicating YAML results. It could specify exact response structure or edge-case behavior, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both nodeId and fileKey are already well documented. The description adds selection context through 'node facts' but does not provide additional parameter semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Inspect') with a clear resource ('node geometry, paint, effects, component and text facts') and an explicit output format ('as YAML'). This makes it readily distinguishable from visual siblings like figma_render or figma_screenshot, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when an agent needs structured node facts rather than rendered output. It does not explicitly name alternatives or state when not to use it, but the context is sufficiently clear for an agent to select it appropriately.
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:
Score Badge
Copy to your README.md: