Server Quality Checklist

Tool Scores

• get_api_usageA
  4.5/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 describes what the tool returns (usage counts, remaining quota) and the environment variable requirement, including anonymous tier behavior. Some additional details like rate limit reset times could improve 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?

  The description is very short and front-loaded, using bullet points for clarity. Every sentence is necessary and provides value with no wasted words.

  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?

  The tool is simple with no parameters and has an output schema (not shown but present). The description covers the return values and prerequisites comprehensively, making it fully complete for an agent to invoke.

  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 has zero parameters, so the baseline is 4. The description adds no parameter information because none is needed.

  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 checks API usage and rate limit status, listing specific APIs (Screenshot, Chart Rendering). It distinguishes itself from sibling tools like render_chart and screenshot_url, which perform different functions.

  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 mentions the prerequisite of HERMESFORGE_API_KEY and fallback behavior without it, providing clear context for usage. It doesn't explicitly state when to use this tool, but the use case is self-evident.

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

• render_chartA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses that the tool returns a Base64-encoded chart image with data URI prefix, and mentions rate limits shared with the screenshot API along with a link to get an API key. It does not cover potential errors, validation, or performance characteristics, but the key behavioral aspects (output format, rate limiting, auth requirement) are addressed.

  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 remarkably concise and well-structured. It opens with a one-sentence summary, followed by bulleted use cases, then an Args section listing parameters with explanations, a Returns line, and a Rate limits note. Every sentence adds value, and the structure makes it scannable for an AI agent.

  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 moderate complexity (rendering a chart from a JSON config), the description covers input parameters, output format, and rate limits. The output schema exists but is not detailed; however, the description clarifies the return type (Base64 image with data URI). It lacks error handling details, but overall it provides sufficient contextual information for basic usage.

  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 input schema has 0% description coverage, so the description must compensate. It does so thoroughly with an Args section explaining chart_config (including a valid JSON example), width and height with defaults, and format with accepted values ('png' or 'jpeg') and default. This adds significant meaning beyond the schema's type and default annotations.

  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 renders a Chart.js configuration as a chart image. It lists specific use cases (visualize data as bar/line/pie/scatter charts, generate charts programmatically, create charts for reports) and the primary verb 'render' with the resource 'chart image' is precise. This effectively distinguishes it from sibling tools (get_api_usage, screenshot_url) which serve 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 Guidelines4/5

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

  The description provides a 'Use this when you need to' section enumerating three common scenarios, giving clear context for when the tool is appropriate. However, it does not explicitly mention when not to use it or compare against alternatives, but the use cases are sufficiently illustrative for an AI agent to infer appropriate usage.

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

• screenshot_urlA
  4.5/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. It discloses the output format (base64), default behaviors, and rate limits. It could mention error handling for invalid URLs or pages that don't load.

  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 well-structured: purpose statement, bullet list of use cases, clear Args section, Returns, and rate limits. Every sentence adds value without redundancy.

  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 (5 params, with output schema), the description covers the main points. It explains the return format and constraints. Missing minor details like error behavior or performance considerations.

  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 is 0%, but the description fully explains each parameter: url (publicly accessible), width/height (viewport, defaults), format (options), full_page (boolean). This adds significant meaning beyond 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 opens with a specific action ('Capture a screenshot') and resource ('any web page'), clearly distinguishing it from sibling tools (get_api_usage and render_chart). The list of use cases further reinforces the purpose.

  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 includes explicit use cases ('Use this when you need to:') and mentions rate limits. It lacks explicit 'when not to use' guidance, but the use cases are specific enough to guide selection.

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