Server Quality Checklist

Tool Scores

• get_primitiveB
  3.3/5.0
  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 transparency burden. It tells the agent the tool 'returns' a composite of four content categories, which clarifies the basic read behavior. However, it does not disclose behavior on errors, invalid primitive names, or whether results are fetched live or cached, which are relevant for a no-annotation 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?

  The description is a single concise sentence that immediately states the return value and scope. Every word contributes meaning, and there is no filler or redundant phrasing.

  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 one-parameter getter, the description covers the input and the high-level content of the output. But with no output schema and no annotations, it omits details about the output shape, failure modes, and the relationship to the overlapping sibling tools. The presence of siblings like get_caveats and get_composition_pattern makes the absence of distinction a real completeness 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 schema already documents the only parameter 'name' with examples like Dialog, Select, and Tooltip, and the description adds the 'Radix UI primitive' context. With 100% schema description coverage, the description does not need to add much, and it does not provide any additional constraint or format detail. 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 clearly states the tool 'returns' a specific resource: the primitive API, accessibility contract, composition pattern, and known caveats for a Radix UI primitive. This is a specific verb-plus-resource formulation that makes the core purpose understandable. However, it does not distinguish itself from sibling tools like get_composition_pattern and get_caveats, which appear to overlap with the returned content.

  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?

  There is no guidance on when to use get_primitive versus list_primitives, get_composition_pattern, or get_caveats. The description does not explain whether this tool is an aggregate, a convenience wrapper, or intended for a different use case. An agent is left to infer the relationship from sibling names alone.

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

• get_composition_patternA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It clearly indicates a read-only lookup that returns advisory output, but it does not cover error behavior for unknown component types, case sensitivity, or whether the result is guaranteed to exist.

  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, well-structured sentence with no filler. It front-loads the core behavior and remains complete without unnecessary detail.

  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 single-parameter lookup tool, the description tells the agent what input to supply and what kind of output to expect. The main gap is the lack of detail about the exact shape or content of the composition pattern, but the tool's complexity is low enough that this is not a critical omission.

  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 100% of the single parameter with a clear description and example. The tool description adds no additional parameter meaning, which is acceptable since the schema already documents the component argument adequately.

  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 ('Returns') and names the exact resource ('recommended Radix primitive(s) and composition pattern') for a given component type. This makes the tool's purpose immediately clear and distinguishes it from siblings like get_primitive or list_primitives.

  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 an agent needs recommended primitives and a composition pattern for a component type. However, it does not explicitly mention when to prefer get_primitive or list_primitives, nor does it state any exclusions or alternative conditions.

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

• get_caveatsA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden. It clearly frames the operation as non-mutating information retrieval ('Returns...') and specifies the content categories returned. It does not describe error behavior for unknown primitives, but for a one-parameter read-only lookup this is a minor 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 front-loads the action and output categories, with no filler or repetition of schema information. Every word 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?

  For a tool with one fully documented parameter and no output schema, the description conveys the return content adequately. It lacks explicit alternatives or edge-case behavior, but the tool is simple enough that an agent can call it correctly with the provided information.

  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 already documents the sole parameter with an example ('e.g. Dialog, Select'), and the description adds no further detail about expected values or constraints beyond the word 'Radix'. With 100% schema coverage, the baseline of 3 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 names a specific verb ('Returns') and a concrete resource ('known issues, workarounds, and version-specific behavior for a Radix primitive'), which clearly differentiates it from sibling tools like list_primitives or get_primitive. An agent can tell immediately what this tool is for without opening the schema.

  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 should be used when caveats or version quirks are needed, but it gives no explicit guidance on when to prefer this over get_primitive or get_composition_pattern. There are no stated exclusions or alternative routing.

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

• list_primitivesA
  4.2/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 the full burden of disclosing behavior. It states both the operation and the output shape: a list of all primitives, each with a one-line description. For a simple zero-parameter enumeration tool, this is sufficiently transparent, though it does not mention ordering, pagination, or exact return format.

  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 verb and resource, then adds the only important output detail: the one-line description per primitive.

  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 list tool with no output schema and no annotations, the description gives enough information for an agent to know what it will get and when to call it. It could optionally mention whether results are sorted or paginated, but for this simple enumeration tool that is not a significant gap.

  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 takes zero parameters, so there is nothing for the description to explain about parameter meaning. The input schema fully covers the input surface, and the description appropriately describes an input-free operation.

  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 identifies a specific verb and resource: it 'Returns all available Radix primitives'. The phrase 'all available' plus 'with a one-line description' distinguishes it from the sibling tool get_primitive, which presumably fetches a single primitive.

  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 this is the tool to use when you need an overall list of Radix primitives, but it does not explicitly say when to use it instead of get_primitive, get_composition_pattern, or get_caveats. Usage context is mostly inferred from the word 'all' rather than stated.

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