Server Quality Checklist

Tool Scores

• describe_imageA
  4.4/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. It discloses the return format ('Returns: A text description of the image') and the action itself, but does not mention any limitations, potential errors, or processing behavior beyond that. It is adequate for a simple read-only tool but lacks richer behavioral context.

  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 with Args, Returns, and Examples sections. It is concise (about 10 lines), every line adds value, and examples illustrate usage clearly. No redundant or filler content.

  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 the tool's simplicity (2 params, no annotations) and the presence of an output schema (though not shown), the description covers all needed aspects: purpose, when to use, parameter semantics, return value, and examples. It is complete for an agent to invoke correctly.

  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 description coverage is 0%, so the description fully compensates. It explains image's format ('file path, URL, or base64') and detail_level's options and default ('brief', 'detailed', 'exhaustive'). This adds significant meaning beyond the bare schema property 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?

  The description clearly states the tool's action ('Generate a text description of an image') and its purpose (caption, alt text, general summary). It differentiates from sibling tools by emphasizing 'without asking a specific question,' which distinguishes it from more query-specific tools like analyze_chart or extract_text.

  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 when-to-use guidance: 'Useful when you need a caption, alt text, or a general summary.' It also implies when-not-to-use by saying 'without asking a specific question,' but it does not explicitly name alternative tools as in the high-calibration example.

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

• extract_textA
  4.5/5.0
  Behavior4/5

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

  With no annotations present, the description carries the full burden of behavioral transparency. It discloses that the tool extracts 'all visible text' and preserves layout 'where possible,' and explains how the language_hint behaves. It does not discuss failure modes, but for a non-destructive OCR tool this is adequate.

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

  Conciseness4/5

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

  The description is well-structured with clear sections for usage, arguments, returns, and examples. It is slightly verbose but every sentence provides useful information, earning a strong score without being overly terse.

  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 tool with two simple parameters and an output schema present, the description is complete. It covers purpose, ideal use cases, parameter semantics, return format, and provides examples. No critical information is missing.

  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, but the 'Args' section fully compensates. It explains that 'image' can be a file path, URL, or base64, and that 'language_hint' is optional with concrete examples. This adds significant semantic meaning beyond the raw 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 'Extract (OCR) all visible text from an image,' which is a specific verb and resource. It distinguishes itself from sibling tools like describe_image and analyze_chart by focusing on text extraction rather than visual appearance.

  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 explicitly identifies ideal use cases: 'screenshots of documents, code, error messages, or any image where the text content matters more than the visual appearance.' This provides clear guidance on when to use the tool, though it does not explicitly state when not to use it.

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

• see_imageA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description takes on the full burden. It transparently discloses accepted input formats (local paths, URLs, base64 strings), explicitly states the return type ('The vision model's answer as plain text'), and gives concrete examples. It does not discuss rate limits, authentication, or error behavior, but for a read-only vision tool this level of disclosure is reasonably informative.

  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 with a one-sentence summary, a usage guideline, clearly labeled Args and Returns sections, and three illustrative examples. Every section earns its place without redundancy or filler. It is concisely written while still providing rich 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 two-parameter tool with an output schema, the description is nearly complete: it covers input formats, default values, return type, and examples. It does not discuss potential limitations (e.g., file size limits, unsupported image types) or offer specific guidance for choosing among sibling vision tools, which would round it out. Given the tool's simplicity, this is a minor omission, hence a 4.

  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?

  Despite the schema's low coverage (0%), the description substantially enriches both parameters. For 'image' it specifies three accepted formats (file path, URL, base64 with or without data-URI prefix) and for 'question' it clarifies semantics and provides a default. This goes far beyond the schema's bare 'string' type, fully compensating for the coverage gap.

  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 verb-resource pair ('Look at an image and answer a question about it') and immediately positions it as the 'core vision tool' for understanding, describing, or reasoning about visual content. This clearly distinguishes it from sibling tools like extract_text (text extraction) and analyze_chart (chart analysis), even though it does not name them explicitly.

  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 offers clear context: 'Use it whenever you need to understand, describe, or reason about visual content that you cannot see.' This tells the agent when to invoke the tool, but it does not provide explicit when-not-to-use scenarios or mention alternative tools by name. Thus it misses the 'explicit exclusions/alternatives' bar for a 5 but is strong enough for a 4.

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

• analyze_chartA
  4.6/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 question is optional and that an empty question triggers general analysis, and it clearly states it returns 'a text analysis'. It also gives examples that clarify expected behavior. It does not mention limitations such as unsupported image formats, but it covers the core behavioral traits transparently.

  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 with 'Args', 'Returns', and 'Examples' sections. It is front-loaded with the core purpose, and every sentence contributes useful information without redundancy. It is appropriately sized for the tool's complexity.

  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 tool with two parameters (one optional) and an output schema, the description is comprehensive. It covers purpose, parameter semantics, return type, and provides concrete examples. The output schema already exists, so the description need not detail return values, and it still gives a concise overview.

  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 schema has zero description coverage, so the description must fully explain parameters. It does so effectively: image is described as 'file path, URL, or base64', and question is explained as optional with behavior defined when 'empty'. This adds significant meaning beyond the raw 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?

  The description opens with 'Analyze a chart, graph, diagram, or UI screenshot', using a specific verb and resource. It further distinguishes itself from siblings by specializing in 'data visualisations, technical diagrams, flowcharts, and UI screenshots where spatial layout and relationships matter', clearly differentiating it from see_image and describe_image.

  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 strong context for appropriate use, stating it is 'Specialised for understanding data visualisations, technical diagrams, flowcharts, and UI screenshots'. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of full explicit guidance.

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