Server Quality Checklist

Tool Scores

• describe_image_structuredA
  3.9/5.0
  Behavior4/5

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

  No annotations were provided, so the description must carry the behavioral disclosure burden. It does so by stating that recognition failure returns '{"error": "..."}' instead of None, which clarifies the failure contract. It also reads as a read-only extraction operation ('extract') and documents the output shape, giving the agent useful information beyond the input schema.

  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 efficiently organized: a one-sentence purpose, an Args section for the parameter, and a Returns section with error handling. It avoids fluff, repeats no schema information, and each line 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 one-parameter tool with no annotations and no output schema, the description covers the required input, the expected return keys, and the failure mode, which is enough for basic invocation. It would be more complete if it gave interaction between 'type', 'note', and 'text' or guidance on which images are out of scope, but nothing critical is missing.

  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 input schema provides only a bare string property named 'image_path', while the description adds that it must be a local image file path ('本地图片文件路径'). That is genuine semantic added value over 'string' and enough to resolve the one required parameter, although it does not discuss supported formats, relative vs absolute paths, or preprocessing behavior.

  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 identifies the action ('extract') and resource ('images with numeric annotations including vectors, matrices, coordinates, angles, unknowns'), which makes the tool's purpose specific and distinct from plain image captioning. It also enumerates the expected return keys, reinforcing the structured-recognition scope. It stops short of a 5 because it never explicitly contrasts itself with the sibling tools 'describe_image' and 'describe_image_stats'.

  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?

  '结构化识别' and the list of extracted quantities imply the intended use: when an agent needs numerical/structured details from an image rather than general description or statistics. However, the description does not explicitly say when to choose this tool over the named siblings or when not to use it, so the guidance is mostly implied rather than stated.

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

• describe_image_statsA
  4.1/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 behavioral disclosure. It documents the return contract (type, categories, series, note, checks), the self-consistency validation behaviors (length alignment, percentage sum, non-negativity), and the failure return format. It does not explicitly say the operation is side-effect-free, but as a local image extractor the return/error contract is reasonably transparent.

  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 dense and front-loaded, with a clear purpose line followed by Args and Returns sections. The only minor flaw is the unexplained '（4.3）' version-like marker, which adds a small amount of noise but does not significantly hurt scannability.

  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 tool with no output schema, the description covers the input semantics, the output dict shape, the validation checks, and the error behavior. It lacks explicit examples and detailed value types for categories/series/checks, but an agent has enough information to select and invoke the tool correctly.

  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?

  Schema description coverage is 0%, and the description compensates by defining image_path as '本地图片文件路径' (local image file path). This is sufficient for the single required parameter, though it could add detail about accepted formats or path resolution.

  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 ('提取' / extract) and a specific resource ('柱状/折线/饼图中的类别与数值序列' — categories and numeric series from bar/line/pie charts). The '统计图 → 数据表' framing clearly distinguishes this tool from the more generic sibling tools describe_image and describe_image_structured.

  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 chart-to-data-table purpose implies when to use it, but the description never explicitly says 'use this when the image is a statistical chart' or 'use describe_image_structured instead for general structured image description.' No alternatives or exclusions are named, so usage guidance is implied rather than stated.

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

• describe_imageA
  4.3/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 behavioral disclosure burden. It adds meaningful traits beyond the schema: supported image formats (jpg/png/bmp), automatic chunking of overlong images ('超长图自动分块'), and the default prompt behavior. It does not discuss external API dependencies or failure modes, but the key runtime behavior is disclosed.

  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 compact and front-loaded: one purpose sentence followed by a two-line Args section with no filler. Every sentence adds either purpose or parameter semantics.

  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 tool with an output schema, the description covers the essential usage context, formats, and defaults. It is not quite complete because it never positions the tool against its siblings or notes constraints such as network/service requirements, but nothing critical is missing for a straightforward call.

  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 by documenting both parameters. image_path is explained as a local path with supported formats and auto-chunking behavior, and prompt is explained as optional with a clear default. This goes well beyond the JSON schema's bare title/type declarations.

  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 and resource: it calls a vision model to observe an image and return a Chinese description ('调用视觉模型观察图片并返回中文描述文本'). The output type is clear, but it does not explicitly contrast itself with the sibling tools describe_image_structured or describe_image_stats, so it stops short of full differentiation.

  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 clearly labels itself as the generic visual description tool ('通用视觉描述') and explains the default prompt behavior, giving an agent enough context to know when the general-purpose description is appropriate. However, it does not explicitly name sibling alternatives or state exclusions, so it does not earn a 5.

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