Server Quality Checklist

Tool Scores

• figma_docsA
  4.2/5.0
  Behavior4/5

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

  No annotations are present, so the description fully carries the burden. It correctly implies a read-only, safe operation by describing documentation retrieval. Could be more explicit about idempotence or safety, but sufficient for a simple doc tool.

  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?

  Two sentences, no wasted words. Purpose and available sections are front-loaded. Ideal structure for quick comprehension.

  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 documentation retrieval tool, the description is complete given the schema coverage. It lacks mention of return format, but that is not critical given the tool's nature.

  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 schema covers the parameter with 100% description coverage, but the description adds value by listing the valid sections explicitly. This aids the agent in understanding available options beyond the schema's generic description.

  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 it provides on-demand documentation for the API and its rules, listing specific sections. It distinguishes from sibling tools like figma_read and figma_write, which focus on design data operations.

  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?

  Usage is implied (when documentation is needed), but there is no explicit guidance on when to use this tool versus alternatives like figma_rules. No exclusions or context cues provided.

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

• figma_statusA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It describes the output components in detail and states 'never a bare boolean', but does not explicitly confirm read-only or non-destructive behavior, though implied. Safety and side effects are omitted.

  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 concise (two sentences), front-loaded with purpose, and every phrase adds value. No unnecessary words.

  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 no-parameter, no-output-schema tool, the description provides a good overview of the diagnostic data returned. It lists multiple components. Could be enhanced with format details, but sufficient for an agent to understand outputs.

  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?

  No parameters exist, and schema coverage is trivially 100%. The description does not need to add parameter info. 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 clearly states the tool provides 'rich connection diagnostics' for the Figma bridge, listing specific elements like connection, leader/follower mode, port, etc. It distinguishes itself from sibling tools (figma_docs, figma_read, figma_rules, figma_write) which handle different operations.

  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 context is clear: this tool is for diagnostics. Siblings have distinct purposes (docs, read, rules, write), so implicit differentiation exists. However, no explicit 'when to use' or 'when not to use' guidance is provided.

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

• figma_readA
  4.3/5.0
  Behavior3/5

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

  With no annotations, the description is the sole source of behavioral info. It mentions token-frugal responses and describes the purpose of layout_audit and read_selection. However, it lacks details on failure modes, authentication needs, or rate limits, which are important for a read tool with many operations.

  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?

  Four sentences with no wasted words. The first sentence front-loads the core purpose, followed by actionable guidance. Each sentence earns its place.

  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 tool's complexity (17 operations, nested params, no output schema), the description covers the main concept and key operations. It could be improved by mentioning typical return values or error handling, but it is reasonably complete for an experienced user.

  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 description adds significant meaning beyond the schema: it explains the 'op' parameter structure and gives concrete examples for 'params' (e.g., { nodeId }, { detail }). It also clarifies the role of specific operations like layout_audit and read_selection, which are not fully defined in the schema.

  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 'Read the Figma canvas', specifying the verb and resource. It also distinguishes from sibling figma_write by implying a read-only scope. The variety of operations is listed, making the purpose unambiguous.

  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?

  It provides context on when to use layout_audit vs read_selection, and mentions the token-frugal nature for efficiency. However, it does not explicitly exclude alternative tools like figma_docs or figma_rules, or provide when-not-to-use guidance.

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

• figma_rulesA
  4.7/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full burden. It discloses parallel fetching and that it is a single call. However, it does not mention permissions, rate limits, or whether the data is cached. Still, it is transparent about the data type and purpose.

  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 that conveys the purpose and usage guideline efficiently. It is front-loaded with the key action and result.

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

  Completeness5/5

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

  Given no output schema, the description explains the return format (markdown) and contents (styles, variables, components). It also advises when to use it. This is complete for the tool's complexity.

  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 input schema has zero parameters, so schema coverage is 100%. The description adds no parameter info, but that is acceptable as there are none. Baseline for zero parameters is 4.

  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 it returns a design-system rule sheet as markdown with styles, variables, and components, fetched in parallel. The name 'figma_rules' aligns with this and distinguishes it from siblings like figma_docs or figma_read.

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

  Usage Guidelines5/5

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

  The description provides clear usage guidance: 'Read before drawing so you reuse tokens/components instead of hardcoding.' This tells the agent when to use this tool and the benefit. It also implicitly distinguishes from other tools that might not aggregate all rules.

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

• figma_writeA
  4.8/5.0
  Behavior5/5

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

  With no annotations, description fully discloses sandbox execution, banned APIs, session state persistence, and return format {ok, result, logs, warnings}, ensuring 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?

  Three sentences, no fluff, front-loaded with action, efficient and structured.

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

  Completeness5/5

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

  Despite no output schema, description covers return values and key behaviors like sandbox restrictions and session persistence, making it complete.

  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?

  Schema coverage 100%, description adds value by explaining code body usage, await figma examples, and sessionId role for state sharing, beyond schema definitions.

  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?

  Description states 'Execute modern-ES JavaScript...to draw/modify the canvas', clearly indicating a write operation on the Figma canvas, distinct from sibling tools like figma_read.

  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?

  Provides context on when to use (draw/modify canvas), but does not explicitly exclude reading or mention alternatives; however, banned functions and session persistence are noted.

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