Server Quality Checklist

Tool Scores

• normalize_pinterest_urlA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral detail beyond those annotations by specifying that the tool removes tracking parameters and produces canonical form, which clarifies exactly what transformation occurs.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that clearly states the tool's purpose and effect with zero wasted words. It is concise, scannable, and all information is relevant.

  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?

  For a simple, single-parameter transformation tool with rich annotations and an output schema, the description is complete. It explains what the tool does, satisfies the behavioral expectations, and does not need to elaborate on return values because the output schema is already provided.

  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 single 'url' parameter with 100% coverage, including the requirement that it be a complete Pinterest or pin.it URL. The description adds a hint about 'supported' URLs but does not significantly extend beyond the schema-provided meaning, so a baseline score of 3 is appropriate.

  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's function: converting a supported Pinterest URL to canonical form and removing tracking parameters. This specific verb+resource combination distinguishes it from siblings like parse_pinterest_url and is_pinterest_url, which have different purposes.

  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 a canonical Pinterest URL without tracking parameters) but does not explicitly mention when not to use it or name alternative sibling tools. The context is clear but lacks direct exclusions or comparison to parse_pinterest_url or is_pinterest_url.

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

• parse_pinterest_urlA
  4.1/5.0
  Behavior4/5

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

  Annotations already identify the operation as read-only, idempotent, and non-destructive. The description adds behavioral detail about the return payload (kind, canonical URL, host, identifiers), which is helpful. No side effects or auth requirements are relevant given the read-only nature.

  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 that leads with the action and resource, then lists the outputs. There is no redundant wording or unnecessary filler.

  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?

  With one simple parameter, a clear description, complete annotations, and an output schema, the description covers everything necessary for an agent to select and invoke the tool. The return values are enumerated, and the output schema can provide further structural detail.

  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%—the 'url' parameter is described as 'A complete Pinterest or pin.it URL'. The tool description adds no further parameter detail beyond what the schema already provides, so the baseline score of 3 is appropriate.

  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 a specific verb ('Parse') and resource ('Pinterest URL') and enumerates the outputs (kind, canonical URL, host, and type-specific identifiers). This differentiates it from sibling tools like is_pinterest_url (a boolean check) and normalize_pinterest_url (canonicalization).

  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—use this when you need structured components from a Pinterest URL—but it does not explicitly name alternatives or state when not to use it. The sibling tools are visible, but no direct comparison is provided.

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

• is_pinterest_urlA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to repeat those. It adds useful behavioral context by stating 'without making a network request,' which is not captured in the annotations. This conveys a key runtime behavior that helps the agent understand the tool's cost and side-effect 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?

  The description is a single, compact sentence that front-loads the primary behavior ('Return whether') and adds a key qualifier ('supported Pinterest URL') and a constraint ('without making a network request'). Every word earns its place; no wasted or redundant phrasing.

  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?

  For a simple boolean validator with one parameter, the description is complete. It explains the core behavior, and the annotations cover safety and idempotency. An output schema exists, so return-value details are not needed. The tool's simplicity means no additional context is necessary for correct 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 has 100% description coverage for the 'url' parameter ('A complete Pinterest or pin.it URL'), so the baseline is 3. The description adds no further parameter semantics, but since the schema fully documents the single parameter, this is sufficient. No gap exists that the description must fill.

  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's function: 'Return whether a value is a supported Pinterest URL.' This is a specific verb+resource combination that distinguishes it from sibling tools like parse_pinterest_url and normalize_pinterest_url, which perform 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 description provides clear context for when to use this tool: 'without making a network request' suggests it is a lightweight, local validation. While it does not explicitly name alternatives, this context differentiates it from parsing or normalizing, which are distinct operations. No exclusions are mentioned, but the usage scope is clear.

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