Server Quality Checklist

Tool Scores

• a11y_suggest_improvementsC
  2.9/5.0
  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 indicates a read-only suggestion action by the word 'suggest,' but it does not disclose output structure, whether issues are required to tailor suggestions, effects on the code, or any limitations. The behavioral disclosure is too thin for a tool with zero annotation support.

  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 extraneous words. It communicates the core action, target, specificity, and output format efficiently.

  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 must supply enough context for an agent to call the tool correctly. It leaves unclear how the optional 'issuess' parameter affects behavior, what the response looks like beyond code examples, and whether an audit or issue list is expected. This is inadequate for confident invocation.

  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 schema covers both parameters fully with descriptions for 'code' and 'issuess.' The description adds only the framing that suggestions are accessibility-specific and include code examples; it does not add syntax, formatting, or behavior details beyond the schema. Baseline 3 is appropriate given 100% schema coverage.

  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 a specific verb ('get'), a resource ('accessibility improvement suggestions'), and a target ('a component'), and adds the outcome 'with code examples.' It is conceptually distinct from the sibling a11y_audit_component, but it does not explicitly name the alternative, so full sibling differentiation is absent.

  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 about when to use this tool versus a11y_audit_component or codegen_react_component. The description implies it is for improving an existing component, but it does not state prerequisites, exclusions, or how it relates to an audit.

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

• codegen_react_componentB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full responsibility for behavioral disclosure. It only claims the output is 'accessible, production-ready code with TypeScript support,' but does not clarify side effects, return format, or whether the tool writes files or returns a code string. For a code-generation tool with no output schema, this is a significant transparency gap.

  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 two short sentences with no filler. The core action is front-loaded, and the second sentence adds relevant quality cues. Every word earns its place without being overly long.

  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?

  The tool has no output schema and no annotations, so the description must explain expected returns and workflow context. It only describes the generation action and output quality, omitting return value, side effects, and how it fits with sibling tools like figma_get_component or a11y_audit_component. An agent would not know what to do with the result.

  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 100%, so the input schema already documents all three parameters, including types, defaults, and purpose. The description adds no new parameter-level information; the mention of 'TypeScript support' loosely maps to includeTypes but does not go beyond the schema description. Baseline 3 is appropriate.

  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 a specific verb ('Generate') and resource ('a React component from Figma component data'), making the tool's core function clear. It does not explicitly name sibling alternatives, but the resource 'React component' is distinct enough from codegen_design_tokens and a11y_audit_component for an agent to infer its primary purpose.

  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: an agent should call this when it has Figma component data and wants a React component. However, it does not explicitly state when not to use the tool, mention prerequisites like calling figma_get_component first, or reference any sibling alternatives, leaving the when-to-use guidance largely implied.

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

• figma_extract_design_tokensB
  3.2/5.0
  Behavior2/5

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

  There are no annotations, so the description must carry the full burden of disclosing behavior. It does not mention that the operation is read-only, whether file access or authentication is needed, what the output format looks like, or any error/edge-case behavior.

  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 two short sentences with a clear front-loaded definition. The second sentence adds meaningful downstream-use context without repetition or fluff.

  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 present, the description should clarify the return shape or token format, but it does not. It also leaves ambiguity around the difference from codegen_design_tokens. For a tool with just one parameter, this may be workable, but the missing return information is a real gap.

  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 single parameter fileKey is already 100% documented in the schema ('The Figma file key'). The description does not add extra semantic detail beyond confirming the file context, which matches the baseline expectation for high schema coverage.

  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?

  Description uses a specific action ('Extract') and resource ('design tokens from a Figma file'), making the tool's core purpose instantly clear. It does not explicitly distinguish itself from siblings like codegen_design_tokens, but the 'extract' vs 'codegen' distinction is implied by the name.

  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 'Useful for generating CSS variables or theme files' gives context for when the tool's output matters, but it offers no explicit guidance on when to choose this tool over siblings such as codegen_design_tokens or figma_get_file. Usage is implied rather than stated with exclusions.

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

• a11y_audit_componentB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It does add useful scope information by enumerating what the audit checks, which helps an agent understand the tool's coverage. However, it does not state whether the tool is read-only, whether it modifies code, what output format is returned, or whether it produces suggestions versus a raw report.

  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 two sentences with no wasted words. The action and target are front-loaded in the first sentence, and the second sentence efficiently enumerates the audit scope. It is appropriately sized for a tool with two parameters.

  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 input side is well covered by the schema and description, but there is no output schema and the description does not describe what the audit returns or how results are presented. For a tool whose primary output is a set of accessibility findings, this is a notable gap, though the tool's purpose is still understandable.

  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 input schema already describes both parameters at 100% coverage, so the baseline is 3. The description does not add meaningful parameter-level detail beyond the schema; it mentions React/HTML, which aligns with the code parameter, but adds nothing about componentName or how the parameters interact.

  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 clearly states a specific verb (audit) and resource (React/HTML component), then lists concrete audit dimensions: WCAG compliance, ARIA attributes, semantic HTML, keyboard navigation, and color contrast. It distinguishes the tool from obvious siblings like a11y_suggest_improvements by framing this as auditing rather than improving, though it does not explicitly name or contrast that sibling.

  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 such as a11y_suggest_improvements or codegen_react_component. There are no conditions, prerequisites, or exclusion criteria; usage is only implied by the word 'audit' and the tool's name.

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

• figma_search_componentsB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It communicates that this is a search operation, which implies read-only behavior, but it does not explicitly state non-mutating behavior, case sensitivity, pagination limits, error handling for empty results, or whether it searches the entire file regardless of nesting. The lack of explicit safety or scope details is a notable gap.

  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?

  A single sentence that wastes no words, places the primary action and resource first, and gives illustrative examples inline. The structure is optimally scannable for an AI agent.

  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?

  For a simple search tool with two required parameters and no output schema, the description covers the essentials of input but omits any description of the return value, matching behavior, or failure conditions. An agent could call it correctly, but it would not know what to expect in response or how to interpret empty/error results.

  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 100%, so the schema already documents both parameters. The description adds meaningful detail for 'query' by clarifying that it accepts a component name or type with examples, but it adds no extra context for 'fileKey' beyond its identification purpose. Baseline 3 is appropriate.

  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 a specific verb ('Search'), a clear resource ('components in a Figma file'), and a search criterion ('by name or type') with concrete examples ('button', 'input', 'form'). It conveys the core function well, though it doesn't explicitly contrast with sibling tools like figma_get_component or figma_get_file.

  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 when to use the tool: when you need to find components by name or type rather than by a known ID. However, it provides no explicit guidance about when not to use it, no mention of alternatives like figma_get_component for direct component access, and no context about file structure or prerequisites.

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

• codegen_design_tokensA
  3.5/5.0
  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 only states the transformation and does not disclose whether the tool fetches from Figma or requires pre-extracted tokens, whether it is pure, what side effects exist, or how output is returned. The phrase 'from Figma design system' is potentially ambiguous given the required 'tokens' parameter.

  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?

  A single front-loaded sentence with no filler. It captures the core purpose efficiently and every word contributes to meaning.

  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?

  For a 2-parameter tool with 100% schema coverage, the description is mostly adequate, but it lacks explicit guidance about whether tokens must already be extracted and provided, and it does not clarify the output delivery mechanism. With no output schema and no annotations, a bit more detail would improve completeness.

  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 100%, so the baseline is 3. The description adds little beyond the schema; it mentions CSS and TypeScript formats but omits scss and json, which are present in the format enum. The 'tokens' parameter meaning is already covered by the schema 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 states a specific verb ('Generate') and resource ('CSS variables or TypeScript design tokens from Figma design system'). It clearly differentiates from siblings like figma_extract_design_tokens (extraction vs. generation) and codegen_react_component (tokens vs. components).

  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 use for generating design tokens from Figma design system data, especially in contrast to figma_extract_design_tokens, but it gives no explicit when-to-use guidance, prerequisites, or exclusions. The usage context is mostly inferred from the tool name and siblings.

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

• figma_get_componentA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full behavioral burden. It conveys a read operation and indicates what information is returned, but it does not disclose authentication requirements, error behavior, or whether the returned variant/property data is complete or paginated.

  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 with no filler. It front-loads the core action and adds useful detail about what the response covers, making it both concise and informative.

  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 two-parameter read tool with no output schema, the description provides enough context to understand the tool's purpose and expected returned content. It could have mentioned where nodeId comes from or clarified fileKey requirements, 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/5

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

  The input schema already documents both parameters with clear descriptions, and schema coverage is 100%, so the baseline is 3. The description does not add meaningful parameter-level guidance, such as how to obtain a valid nodeId or whether nodeId needs encoding.

  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 'Get', identifies the resource as 'a specific component in a Figma file', and lists concrete content areas (properties, variants, styling). This clearly distinguishes it from siblings like figma_get_file and figma_search_components.

  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 details about an already-known component, but it does not explicitly mention alternatives such as figma_search_components for discovery or state when not to use it. There is no direct routing guidance, only an implied use case.

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

• figma_get_fileA
  4/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the behavioral disclosure burden. 'Fetch' clearly marks this as a read-only operation, and 'full file tree including all pages, frames, and components' discloses the response scope. It does not discuss authentication or large-payload concerns, but it covers the basic behavioral profile.

  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 short sentences, action-first, with no wasted words. The second sentence usefully expands on the return shape rather than repeating the first.

  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 tool with one required parameter and no output schema, the description plus schema is sufficient to call it correctly. It could add sibling-routing guidance or a note about potentially large responses, but nothing critical for basic invocation is missing.

  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, fileKey, is fully documented in the schema with a URL extraction hint, so schema coverage is 100%. The description adds no additional parameter meaning, which is acceptable because the field is self-explanatory.

  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 uses a specific verb ('Fetch') and resource ('Figma file structure and metadata'), then specifies output scope: the full file tree including all pages, frames, and components. This clearly distinguishes it from sibling figma_get_component, which targets a single component.

  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?

  No explicit when-to-use guidance or mention of alternatives is provided. The phrase 'full file tree' implies whole-file operations, but the agent must infer how this differs from figma_get_component and other siblings.

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