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

There are no annotations, so the description bears the transparency burden. It discloses the vision-model dependency and that output is plain text. However, it does not mention potential limitations, error behavior, or whether any authentication or prerequisites apply, leaving some behavioral uncertainty.

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

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

Three short, front-loaded sentences with no filler. It states purpose, use case, and supported modes efficiently. Every sentence earns its place.

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

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

For a simple general-purpose vision tool, the description is mostly complete: it names the model limitation, output type, and single/multi-image support. However, it does not explicitly differentiate from specialized siblings or clarify whether a prompt is expected if not provided, leaving minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds a small clarification that single vs. multi images are supported via 'image' or 'images', but this mostly repeats what the schema already explains. It does not add meaningful new semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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: 'Analyze one or more images with a vision model and return plain text.' It also distinguishes itself from sibling tools by framing itself as 'general Q&A when the host model cannot see images,' setting it apart from specialized tools like ocr_image or compare_images.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It explicitly says when to use: 'Use for general Q&A when the host model cannot see images.' This gives clear for-use context, but it does not explicitly mention when not to use specialized alternatives (e.g., describe_image, ocr_image), so it earns a 4 rather than a 5.

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

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 correctly conveys a read-only comparison behavior, but does not disclose output format, handling of remote images (only in schema), or any limitations. It is adequate but not rich in 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.

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

The description is concise, with just two sentences. It front-loads the core purpose and then lists concrete use cases. There is no redundancy or filler, making it highly scannable for an agent.

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

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

The description clearly explains what the tool does and when to use it, but with no output schema or annotations, it lacks details about the response format, error handling, or constraints like maximum image count. It is sufficient for a straightforward tool but leaves some context to be inferred.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides detailed descriptions for all parameters, including examples for the 'images' array. The description reinforces the comparison purpose but does not add new parameter-level semantics beyond what the schema already states, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's core function: 'Compare two or more images and explain similarities/differences.' It uses a specific verb and resource, and the examples (before/after, A/B UI, design variants) make it easy to distinguish from sibling tools like analyze_image or describe_image.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The 'Use for' clause gives explicit scenarios (comparing image 1 and 2, before/after, A/B UI), providing strong guidance on when to invoke this tool. However, it does not explicitly mention alternatives or when not to use it, though the sibling tool list offers context for exclusion.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It states the output is a textual description for text-only models, implying a read-only, non-destructive operation. It also adds context about handling multiple images, but omits details like output length or potential limitations, which keeps it from a 5.

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

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

The description is just two sentences, with the primary action front-loaded and a concise usage hint in the second sentence. It contains no redundant information and earns its place entirely.

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

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

The tool has a comprehensive input schema and a description that covers its main purpose and appropriate use cases. Since there is no output schema, the mention of 'detailed textual description' adequately communicates the return type. The description is sufficient for the tool's complexity, though it could have added examples or error behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% coverage of parameter descriptions, setting a baseline of 3. The description enriches this by noting the 'multi-upload context dumps' use case, which clarifies the intended usage of the 'images' parameter and adds value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: producing a detailed textual description of images. The phrase 'general scene/UI understanding and multi-upload context dumps' distinguishes it from specialized siblings like ocr_image or read_chart, making the purpose specific and differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explicitly states when to use the tool ('Prefer for general scene/UI understanding and multi-upload context dumps'), providing clear context for selection. However, it does not name specific alternative tools or exclusion conditions, so it stops short of full when/when-not guidance.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It only says 'Explain ... for a text-only agent'; it does not mention multi-image handling, label semantics, whether the explanation is a textual narrative, or any limitations.

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

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

Single sentence, front-loaded with the verb and subject, and every word earns its place. No redundancy or filler.

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

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

With no output schema and no annotations, the description is minimal but adequate for a moderately complex vision tool. It misses details about return format and multi-image behavior, which are important given the 'images' parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with detailed descriptions for image, images, prompt, and mimeType, so the baseline is 3. The tool description adds no additional parameter semantics beyond the general diagram context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Explain') and enumerates concrete resource types (architecture diagrams, flowcharts, sequence diagrams, ERDs, UML, whiteboards), clearly distinguishing it from sibling tools like describe_image or read_chart. The phrase 'for a text-only agent' adds audience specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies appropriate use by listing diagram categories and noting the tool is for a text-only agent, but it does not explicitly state when to prefer this over siblings or when not to use it. Still, the context is reasonably clear.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose a meaningful behavioral trait: 'Optional schema steers field names', indicating how the schema parameter affects output. However, it does not mention whether the tool is read-only, how images are handled, or any limitations or side effects, leaving gaps in transparency.

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

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

The description is a single, concise sentence that immediately states the tool's core function and adds relevant examples. There is no wasted wording, and every clause contributes to understanding the tool's purpose and key behavior (schema steering).

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

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

Given the tool has 5 parameters, no output schema, and no annotations, the description provides enough context for an agent to understand the primary use case and output type (JSON). The rich schema descriptions fill in parameter details, but the description could more explicitly describe the shape of the return value (e.g., object vs array) and any edge cases. Overall, it is adequately complete but not exhaustive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% description coverage for all parameters, so the baseline is 3. The description adds a small amount of context by explaining that schema influences field names, but this is already implied in the schema's own description. No additional parameter-level meaning is provided beyond what the schema already covers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Extract') and resource ('images'), and clearly states the output is 'structured data (JSON)'. The enumeration of document types (forms, receipts, IDs, tables, invoices, labels) distinguishes it from sibling tools like describe_image or ocr_image, making the tool's unique purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 the tool by listing concrete document types (forms, receipts, IDs, tables, invoices, labels). However, it does not explicitly mention when not to use it or name alternative tools for different tasks, such as ocr_image or describe_image, so it stops short of full exclusion guidance.

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

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 that the tool inspects UI screenshots for specific categories and can handle multiple images, but does not describe output format, limitations, or side effects (though read-only by nature).

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

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

The description is two sentences, front-loaded with the core purpose, and every word adds value. No filler.

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

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

The tool is relatively simple, and the description covers the input modes (single or multi-image) and the scope of analysis. However, with no output schema, it would benefit from stating what the tool returns, though the inspection context implies a textual report.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for image, images, prompt, and mimeType. The description's phrase 'multi-step flow' adds a small nuance to the images parameter, but overall it does not exceed the schema's detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Inspect' with resource 'UI screenshots' and lists concrete aspects (layout, components, states, copy, errors, UX/accessibility). This clearly distinguishes it from siblings like analyze_image or describe_image, which are more generic image analysis tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description states it accepts 'one screen or a multi-step flow', giving clear input context. It doesn't explicitly mention alternatives or when-not-to-use, but the UI focus implicitly guides selection over generic image tools.

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

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

No annotations are provided, so the description carries the burden. It does disclose that multi-image calls 'return a section per image label', which is a useful behavioral trait. However, it omits potential limitations (e.g., language support, handwritten text, supported formats) or side effects, leaving a moderate transparency level.

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

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

The description is extremely concise: two sentences. The first sentence states the primary purpose, and the second adds the key multi-image behavior. Every word earns its place with no filler or redundancy.

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

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

For a 4-parameter tool with a rich schema and no output schema, the description covers the core purpose and important multi-image output behavior. It could have added explicit differentiation from the similar-sounding 'extract_from_images' sibling, but the overall context is sufficient for selecting this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and every parameter already has detailed meanings in the schema. The description's mention of 'a section per image label' adds context to the images array's label property, but that is minor. It doesn't further explain parameters beyond the schema, so the baseline of 3 holds.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Extract readable text from one or more images' – a specific verb and resource that clearly defines OCR functionality. Examples (screenshots, documents, diagrams, error dialogs) further clarify the intended use. The multi-image note distinguishes it from single-image analysis tools like describe_image or analyze_image.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description clearly implies when to use: whenever readable text needs to be extracted from images, with multiple image example types. The multi-image behavior is stated, but there is no explicit exclusions or naming of alternative tools (e.g., extract_from_images) for when not to use this tool.

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

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 a key behavioral trait: 'marks estimates when exact pixels are unclear', which adds transparency about output reliability. It also implies a read-only, non-destructive operation, though it could further explain output format or limitations.

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

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

The description is two short sentences, front-loaded with the tool's core purpose and immediately followed by extraction details. Every clause provides value—no filler or repetition of the tool name.

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

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

Without an output schema, the description helps by listing what is extracted (axes, series, trends, key values) and the estimate behavior. The parameter schema covers multi-image usage, so the description doesn't need to repeat that. It's sufficient for a read-only chart tool, though it could be more explicit about return structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific details beyond what the schema already documents. It doesn't explain the difference between 'image' and 'images' or how the 'prompt' parameter modifies behavior, but the schema itself is thorough.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Read') and resource ('charts, graphs, plots, tables, and dashboards'), and enumerates what it extracts ('axes, series, trends, and key values'). This clearly distinguishes it from sibling tools like ocr_image or describe_image, which handle different tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 the tool (any chart-like visual input) but does not explicitly mention alternatives or when not to use it. The context is specific enough for an agent to decide, but it stops short of naming sibling tools or exclusions.

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

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 a meaningful behavioral trait ('Grounds every claim in image labels') but does not mention output format, error handling, or potential side effects. This is a minimal but non-empty disclosure.

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

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

The description is two sentences, front-loaded with the core purpose, and uses illustrative examples without fluff. Every word earns its place, and the structure is clear and readable.

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

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

For a Q&A tool with no output schema, the description adequately conveys the core use case, differentiates from many siblings, and aligns with the schema's parameter intent. It lacks explicit return-value specifications, but the schema and examples cover the main selection and invocation needs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, which sets a baseline of 3. The description adds examples of label usage and prompt wording, reinforcing the schema's label semantics, but does not introduce meaning beyond what the schema already details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Answer') and a clear resource ('question that refers to specific uploads by label'). It provides concrete examples ('refer image 1 and 2', 'only the second screenshot') and distinguishes from sibling tools by focusing on multi-image labeled references and grounding claims in labels.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives clear context for when to use the tool through examples of referring to specific uploads by label. However, it does not explicitly mention when not to use it or name alternative sibling tools, so it stops short of full guidance.

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

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

No annotations are provided, so the description carries the burden. It clearly indicates a read-only operation ('Show') with a well-defined scope (server configuration). However, it does not mention output format, potential errors, or whether any network calls are made, which are minor omissions for such a simple status tool.

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

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

The description is a single, well-structured sentence that immediately states the main purpose. It includes all necessary information without redundancy or filler.

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

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

For a no-input, read-only status tool, the description is complete. It states exactly what the tool shows (provider/model and image limits), which is sufficient since there is no output schema to explain and no parameters to document.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema is empty. The description adds no parameter-specific meaning because none are needed. With zero parameters, a baseline of 4 applies, and there is no gap to compensate for.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Show') and clearly identifies the resource: the configured vision provider/model plus image limits. It distinguishes itself from the sibling image-analysis tools, which are all about processing images rather than reporting server configuration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The tool's role as a status/config query is implied by the description, but there is no explicit guidance on when to use it versus the image-analysis siblings. No alternatives or exclusions are mentioned, only a clear contextual inference from the tool name and siblings.

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