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

The description fully discloses key behaviors: streaming with a 20MB cap, content-type guard, SHA-256 hashing, and a host blocklist. Since no annotations are provided, this information is critical for safe and correct usage.

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 concise sentences with no redundancy. The first sentence states the purpose, the second lists technical details, and the third adds a restriction. Information is front-loaded and every sentence adds value.

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 covers the tool's purpose, key behaviors, and return value (cached file path). It is mostly complete for a download tool, but lacks details on optional parameters and how they affect 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 description mentions a '20MB hard cap' which correlates to the maxBytes parameter but does not explain it or the cacheDir parameter. With 0% schema description coverage, the tool relies heavily on the description to clarify semantics, missing the opportunity to describe optional parameters.

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 'Download' and resource 'image URL', clearly stating the action and result (cached file path). It distinguishes itself from sibling tools like 'search_images' or 'fetch_with_license' by emphasizing local disk caching and typical usage from search results.

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 mentions 'typically from a prior search_images result', providing a clear context for when to use this tool. However, it does not explicitly state when not to use it or mention alternative tools for different scenarios.

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?

Given no annotations, the description carries full burden; it discloses heuristics, page metadata scanning, and the probe parameter triggering download. Sufficiently transparent for a simple 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?

Two sentences, no unnecessary words. First sentence describes function, second provides usage guidance. Efficient.

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?

No output schema, but description implies return of license info. For a 2-param tool, it covers behavior and usage. Could mention return format or error handling.

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 has 0% description coverage, but the description explains the url parameter as target and probe parameter as triggering download, adding 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 verb 'determine its license' and the resource 'URL', and distinguishes from siblings like download_image and search_images through its specific function.

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?

Provides explicit usage context: 'Use when an agent already has a URL and needs a go/no-go decision before shipping.' Lacks explicit alternatives or when-not-to-use, but the context is 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 provided, so description carries the burden. It adds 'Returns candidates with heuristic licenses — treat results as leads, not shippable,' disclosing the heuristic nature and appropriate usage, which is valuable behavioral context beyond basic purpose.

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 sentences with no redundancies: purpose, prerequisite, output disclaimer. Each sentence serves a distinct, essential function.

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 no output schema and no annotations, the description covers purpose, a key prerequisite, and output quality. It does not address error cases or rate limits, but the tool is low-complexity with 2 params.

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 50% (url has description, providers does not). Description adds 'Requires ... providers: ["serpapi"]', indicating the required provider and hinting at the role of the providers parameter. However, it does not explain individual enum options, which the schema already lists.

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?

Description clearly states 'Reverse-image-search: given a public image URL, find visually similar images.' This is a specific verb+resource combo, and it distinguishes from sibling tools like download_image or search_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?

Description mentions requirement 'Requires SERPAPI_KEY env var and providers: ["serpapi"]', giving clear context for when to use. It does not explicitly exclude alternatives, but the prerequisite is helpful.

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 respects robots.txt and returns images with dimensions and license. This is transparent about its behavior, though it could mention error handling or performance.

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 that pack all necessary information. No redundant words. It front-loads the core action and then provides usage context.

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 tool with no output schema and moderate complexity, the description covers what the tool returns (images with dimensions and license) and its default behavior (respects robots.txt). The context is sufficient for an agent to understand when to invoke it among siblings.

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?

Input schema has 2 params (url, respectRobots) with 0% description coverage. The description clarifies the purpose of the tool and implies usage of both params (url as input, respectRobots via default respect). It adds meaning beyond the raw schema, especially for the boolean parameter.

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 action (return every <img> on a webpage), the resource (given a URL), and the output (images with dimensions and license). It distinguishes itself from siblings like download_image or fetch_with_license by focusing on triaging a source page.

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?

Explicitly states 'Use to triage a candidate source page before picking', indicating the intended use case. It also mentions respecting robots.txt by default, providing a constraint. However, it does not explicitly state when not to use or mention alternatives.

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?

Discloses that results are editorial-licensed and safe per ToS, which is key behavioral info. No annotations provided, so description covers safety. Could add more on failure modes or rate limits.

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?

Two sentences, efficient and front-loaded. However, lacks structure or parameter hints. No wasted words, but could be slightly more informative.

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 9 parameters and no output schema, description is incomplete. It doesn't explain return format or behavior for missing results. Adequate for a simple search but not comprehensive.

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 0%; description does not mention any parameters despite there being 9, including required ones. Schema is detailed, but description fails to add meaning beyond it.

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?

Description uses specific verb 'Find' and resource 'canonical album artwork', clearly distinguishing from sibling tools like search_images and search_artist_images. Mentions specific data sources (MusicBrainz, iTunes, Spotify) and licensing.

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?

States use case 'album identification UI' and attribution requirement. Implicitly differentiates from siblings but lacks explicit when-to-use vs alternatives. Clear context provided.

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. It explains the behavioral differences based on the 'kind' parameter (provider sets and query expansion). However, it does not disclose any other behavioral traits such as read-only nature, pagination, or rate limits.

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 a few sentences, front-loaded with the purpose. It could be more structured, but it is not overly long and gets to the point.

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 lack of output schema and missing parameter descriptions, the description should be more comprehensive. It only covers the 'kind' parameter and one usage scenario, leaving many parameters and the return format unexplained.

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 0%, so the description must compensate. It only explains the 'kind' parameter in detail; the other 8 parameters (like safeSearch, licensePolicy, maxPerProvider, etc.) are not described at all. This adds minimal 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 it is a specialized image search for a musical artist, and explicitly distinguishes this tool from sibling search_images by saying 'Prefer this over search_images when building artist/band content.' It also explains the purpose of the 'kind' parameter with specific provider sets.

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 explicit guidance on when to use this tool over search_images for artist/band content. However, it does not mention when not to use it or provide alternatives for other contexts, and lacks details about other sibling tools like search_album_cover.

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?

Discloses search behavior (federated, license-aware), return format (candidates with license+attribution), and safe policy details. No annotations provided, so description carries burden; could mention failure modes or limits, but overall good 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?

Description is fairly concise and front-loaded with key information (search purpose, no auto-download, policy). A few clauses (e.g., 'Default safe-only policy includes...') could be tightened, but overall efficient.

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 8 parameters, no output schema, and complex providers, description covers search scope, license awareness, policy, and pointer to download_image. Missing output format details but adequate for use.

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?

Description mentions query and providers implicitly but does not explain parameters beyond schema. Schema coverage is low (13%), yet description adds minimal parameter guidance (e.g., no details on timeoutMs, minWidth, etc.).

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 it performs 'Federated image search across license-aware providers' and returns 'concise ranked candidates with license + attribution.' It distinguishes from sibling tools like download_image which handles downloading.

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?

Explicitly states when not to use ('Does NOT auto-download — call download_image after'), describes default policy and when to use open-only, and suggests using CLI for large batches.

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