Server Quality Checklist

Tool Scores

• ask_imageB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, and the description is too minimal to disclose behavioral traits. It does not mention limitations (e.g., image formats, size), network usage, or what happens with the image. The agent gets no insight into side effects or requirements beyond the bare function.

  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 concise and front-loaded. The first sentence states the purpose, and the Args section clearly lists parameters with brief explanations. No wasted words or redundant content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having an output schema, the description is incomplete for a tool with no annotations. It does not mention expected output structure, error conditions, or any constraints. Given the sibling tools, it also fails to position itself contextually. The description is adequate for the simplest case but lacks depth.

  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 schema provides only parameter titles with 0% description coverage. The description adds meaningful semantics: 'Absolute path to the image file' clarifies that image_path must be filesystem-absolute, and 'Your question or prompt about the image' clarifies the question parameter. This compensates well for the lack of schema descriptions.

  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 'Ask any question about an image' clearly states the tool's function with a specific verb and resource. It distinguishes itself implicitly from sibling tools like describe_image and ocr_image by focusing on arbitrary questions, though it does not explicitly differentiate them.

  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 this tool versus alternatives such as describe_image or ocr_image. The description simply states what it does without any prerequisites, exclusions, or context for choosing it.

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

• describe_imageA
  3.5/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 implies a read-only operation but doesn't explicitly state side-effect-free behavior or limitations. It does list acceptable file formats and detail levels, providing some 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 compact and well-structured: a clear one-sentence purpose followed by an Args block. Every line is informative, and the format is easy to scan.

  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?

  The description fully specifies the tool's inputs and purpose, which is sufficient for a straightforward 2-parameter read-only tool. Output semantics are handled by the output schema. It doesn't reference sibling tools, but that gap is captured in usage_guidelines.

  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 coverage is 0%, so the description compensates by explaining both parameters. image_path specifies absolute path and supported formats, and detail_level enumerates the allowed values. This adds meaningful context beyond the raw schema.

  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's function: describing the content of an image file. The verb 'describe' and resource 'image file content' distinguish it from sibling tools like ocr_image or ask_image, though it doesn't explicitly name those alternatives.

  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?

  No guidance on when to use this tool versus the sibling tools (ocr_image, ask_image, process_clipboard_image). The description only lists the arguments and their meanings, leaving the agent to infer usage context.

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

• ocr_imageA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the behavioral transparency burden. It only states the core action and language parameter, but omits details such as supported image formats, error behavior, limitations, or permission requirements. This leaves the agent with little beyond the raw function purpose.

  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 sentence for the purpose plus a short Args list. Every sentence adds useful information and there is no filler.

  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 OCR tool with an output schema present, the description covers the primary behavior, arguments, and language scope. The main gap is the lack of explicit guidance on when to choose this tool over sibling image tools, but overall it is sufficiently complete for the tool's complexity.

  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 has 0% description coverage, but the description compensates well by explaining image_path as an absolute path and language as a hint with explicit supported values. It does not mention that language is optional or how auto-detection interacts, so it is not perfect.

  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 and resource: 'Extract all visible text from an image (OCR)'. This clearly distinguishes it from sibling tools like describe_image or ask_image, 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 Guidelines3/5

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

  The description implies use when text extraction from images is needed, but it never explicitly states when to use this tool versus sibling tools, nor does it mention any exclusions or alternatives. The absence of explicit guidance makes it only minimally useful.

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

• process_clipboard_imageA
  4.4/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 burden. It discloses that the primary model has no vision capability and that the tool reads the clipboard image and analyzes it, which is essential context. It doesn't mention edge cases like empty clipboard, but for a read/analyze operation, the core behavior is 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 compact and front-loaded with the core purpose. The 'IMPORTANT' repetition and Args section are slightly redundant but not bloated. Overall structure is logical and efficient.

  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 one-parameter tool with an output schema, the description covers purpose, usage triggers, and parameter semantics well. It lacks explicit error behavior (e.g., no image on clipboard) and doesn't name sibling tools for file-based images, but it is sufficient for an agent to invoke it 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?

  The schema provides 0% parameter descriptions, but the description compensates fully by explaining the 'task' parameter: 'describe', 'ocr', or any custom question, plus the default value. This gives practical usage semantics beyond the bare 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 uses a specific verb ('process') with a specific resource ('image from the macOS clipboard') and clearly states what it does: reads and analyzes clipboard images. It differentiates from siblings by specifying 'without a file path' and 'paste from clipboard', making the scope unambiguous.

  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 gives explicit trigger conditions: 'Call this whenever you see [Image 1]... or the user pastes an image from clipboard.' It also implies when-not by saying 'without a file path', but it does not explicitly name alternative sibling tools for file-based images. This is clear context with a minor omission.

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