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 tool is read-only (listing capabilities) and details the return structure. However, it does not explicitly state that it does not modify server state, but this is clear from 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 somewhat lengthy but well-structured with sections (Args, Returns, Tips, Example). The first sentence delivers the core purpose, and every section adds value. Minor redundancy in the returns section listing what's in the JSON.

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?

Despite no output schema, the description fully explains the return values (catalogs, collections, band mappings, spectral indices) and provides a typical workflow and example. It completely covers what an agent 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?

With 0% schema description coverage, the description fully compensates by documenting the only parameter 'output_mode' with allowed values (json/text) and default, adding meaning 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 purpose: 'List server capabilities: catalogs, collections, and band info.' It distinguishes itself from sibling tools (e.g., stac_search, stac_describe_scene) by being a top-level discovery tool.

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 'Tips for LLMs' section explicitly advises calling this tool first, provides a typical workflow, and explains when to use it vs. other tools. This is exemplary 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?

With no annotations, the description carries the full burden. It explains that the tool automatically downloads required bands, computes the index formula, and stores the result as a single-band float32 raster. It also describes the return format (JSON with artifact_ref and value_range). No contradictions with annotations (none provided). Could mention potential storage implications, but overall transparent.

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 somewhat lengthy with full formulas and tips, but it is well-structured: summary, supported indices list, args, returns, tips, example. Every section adds value, though a few details (like exact formulas) could be condensed if redundancy is avoided.

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 6 parameters, no output schema, and no annotations, the description is comprehensive. It explains inputs, outputs, usage context, and provides interpretation tips. It feels complete for an AI agent to invoke correctly.

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 0%, so the description must compensate. It provides detailed parameter descriptions: scene_id, index_name with list and formulas, bbox format, cloud_mask explanation, output_format vs output_mode, and interpretation guides. This adds significant meaning beyond the raw schema, making it easy for an AI to use correctly.

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 computes a spectral index like NDVI or NDWI for a scene. It specifies the verb 'compute' and the resource 'spectral index', distinguishing it from sibling tools like 'stac_download_bands' or 'stac_temporal_composite'.

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 usage context such as 'Only works for optical collections (Sentinel-2, Landsat)' and suggests using 'stac_capabilities' to see available indices. It advises enabling 'cloud_mask=True' for cleaner results and notes temporal change analysis. However, it does not explicitly state when not to use this tool 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?

No annotations provided, so description carries full burden. It explains the rasterization process and output format, but doesn't mention read-only nature or other behavioral traits like rate limits. Still transparent enough for safe use.

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?

Well-structured with Args, Returns, Tips, and Example. Each section is useful, though slightly verbose. Front-loaded with the main purpose.

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 explains the JSON return format with coverage percentage and uncovered areas. Adequately complete for the tool's purpose.

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 0%, so description fully compensates by explaining bbox format (EPSG:4326), scene_ids requirement (cached from stac_search), and output_mode default. Adds meaning 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 'Check if cached scenes fully cover a requested bounding box,' using a specific verb and resource. This distinguishes it from siblings like stac_mosaic and stac_search.

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 guidance: 'Call this before stac_mosaic to verify scenes fully cover your area of interest' and tips for handling insufficient coverage. Also specifies scenes must be from prior stac_search.

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 behavioral disclosure. It describes the return content for known collections (rich metadata) and unknown collections (live STAC metadata). It also mentions the output_mode parameter and warns about cloud_mask_band being None for non-optical collections. This is transparent about what the tool does and does not do.

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 well-structured with a clear first line, bullet-like list of returns, then sections for Args, Returns, and Tips. Every sentence adds value—there is no verbosity or redundancy. It is front-loaded with the core purpose, then progressively elaborates.

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?

Despite having no output schema and 3 parameters, the description covers what an agent needs: expected return content (band details, composites, indices, guidance), handling of unknown collections, parameter options, and integration tips with sibling tools (e.g., stac_download_bands). It also addresses an edge case (cloud_mask_band None). This is comprehensive for the tool's relatively simple role.

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?

With 0% schema description coverage, the description fully compensates by listing each parameter with its options (e.g., collection_id options: sentinel-2-l2a, landsat-c2-l2, etc.; catalog options: earth_search, planetary_computer, usgs; output_mode options: json or text). This adds significant meaning beyond the schema's basic type/required information.

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 begins with a clear statement of purpose: 'Get detailed information about a STAC collection.' It specifies what is returned (band wavelengths, composites, spectral indices, etc.) and distinguishes from sibling tools by focusing on collections (vs. scenes or listings). The verb 'describe' and object 'collection' are specific and 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 includes a 'Tips for LLMs' section that explicitly recommends calling this tool before using stac_download_bands, and advises checking cloud_mask_band for non-optical collections. This provides clear usage context but does not directly compare with alternative sibling tools (e.g., stac_search or stac_list_collections) nor 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.

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

No annotations provided, so description carries full burden. It explains what is returned but does not disclose behavioral traits like read-only nature, authentication, or error handling. Adequate but not thorough.

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?

Well-structured with purpose, args, returns, tips, and example. No unnecessary sentences; every part 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?

For a tool with 2 parameters and no output schema, the description covers purpose, inputs, expected output, and usage context. Includes tips linking to stac_download_bands, making it complete.

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?

With 0% schema description coverage, the description compensates fully: explains scene_id as a search result identifier and output_mode as format with default. Adds meaning 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 'Get detailed information' and the resource 'scene'. It distinguishes from siblings like stac_describe_collection and stac_search by focusing on a single scene's details.

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 prerequisite ('scene must have been returned by a previous stac_search call') and provides context for when to use ('after stac_search'). Does not explicitly exclude scenarios but offers clear 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?

With no annotations, the description carries full burden. It discloses that it reads COGs via HTTP, windows to bbox, stores in chuk-artifacts, handles CRS reprojection, auto-generates PNG preview. It does not explicitly mention limits or auth, but adequately covers the core behavior. Minor gap in listing potential side effects.

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 well-structured with clear sections (intro, Args, Returns, Tips, Example). While somewhat verbose, every sentence adds value. The front-loading of the main purpose and tips makes it efficient. Could be slightly more concise, but clarity is excellent.

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's complexity (6 params, no output schema, no annotations), the description covers all necessary context: parameter semantics, return value format, usage tips, and a concrete example. It compensates for the missing schema descriptions and output schema.

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 provides detailed explanations for all six parameters, including examples for band names per satellite, bbox format, output format choices, cloud mask scope, and output mode. This adds significant meaning beyond the raw 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 'Download specific bands from a scene as a GeoTIFF or PNG.' The verb 'download' and resource 'bands from a scene' are specific. It distinguishes from siblings by explicitly mentioning alternatives like stac_download_rgb and stac_compute_index.

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 'Tips for LLMs' section provides explicit guidance: use stac_describe_scene first, always provide a bbox, prefer png for viewing, geotiff for analysis, and prefer sibling tools for RGB or indices. It clearly states when to use this tool vs 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?

No annotations exist, so description carries full burden. Discloses band order mapping, cloud_mask limitation (Sentinel-2 only), output formats, and return format. Lacks explicit statements on side effects or auth needs, but overall transparent.

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?

Well-structured with sections (Description, Args, Returns, Tips, Example). Slightly long but every sentence adds value. Could be slightly more concise, but appropriate for complexity.

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, description covers parameters, usage, return format, and alternatives. Lacks error handling or invalid input behavior, but sufficient for agent invocation.

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, so description must compensate. It explains all parameters: scene_id from search, bands with examples, composite_name, bbox, output_format, cloud_mask, output_mode. Adds recipes and tips beyond 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 'Download a multi-band composite from a scene' and explicitly distinguishes from siblings like stac_download_rgb and stac_compute_index, making the 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?

Provides explicit guidance: 'For true-colour RGB, use stac_download_rgb instead' and 'For single-value analysis, use stac_compute_index'. Also suggests using stac_describe_collection to see recipes, offering alternatives and context.

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, the description carries full burden. It states it is a convenience wrapper, automatically selects bands, applies cloud masking optionally, and returns JSON with artifact_ref. It does not mention side effects (likely none), but is transparent about constraints (optical only). Minor gap: no explicit mention of idempotency.

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?

Well-structured with summary, args, returns, and tips. Every sentence serves a purpose. The 'Tips for LLMs' is slightly long but adds practical value. Could be slightly more concise, but overall effective.

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, description explains return format (JSON with artifact_ref). It covers parameters, usage context, and tips. Missing explicit error handling or prerequisites beyond optical collections, but still fairly complete for a 5-parameter 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 coverage is 0%, so description must compensate. It describes scene_id, bbox (strongly recommended), output_format (geotiff vs png with use cases), cloud_mask (SCL-based, Sentinel-2 only), and output_mode (json or text). It adds value beyond schema, e.g., why bbox is important and when to use PNG. However, output_mode's options are not fully detailed.

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 downloads a true-color RGB composite from a scene, distinguishing it from stac_download_bands (convenience wrapper) and stac_download_composite (false-color). The verb 'download' and resource 'RGB composite' are specific and 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?

Explicitly provides when to use (RGB visual) and when not (false-color -> use stac_download_composite). Includes tips for LLMs on output_format choices, and states it only works for optical collections. This is comprehensive 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?

With no annotations provided, the description carries the full burden. It discloses that no pixel data is read (only COG headers), making it very fast. It describes the return format (JSON with per-band size details) and provides tips about band size comparisons. While thorough, it does not address error handling or edge cases, which would push it to 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 well-structured: a one-line summary, followed by Args, Returns, Tips for LLMs, and an Example. Every sentence adds value, and the structure is front-loaded with the core purpose. It is concise yet comprehensive.

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's moderate complexity (4 params, 2 required, no output schema, no annotations), the description is complete. It covers all parameters, return values, use cases, and tips for integration with sibling tools (mosaic, composite). The example rounds out the completeness.

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 0%, so the description must compensate. It explains each parameter: scene_id, bands (with examples), bbox (format and CRS), and output_mode (default and alternatives). The example further clarifies usage. This adds substantial meaning beyond the bare 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 purpose: 'Estimate download size for bands from a scene (no pixel data read).' It specifies reading only COG headers to determine dimensions, dtype, and estimated file size. This distinguishes it from download tools and sibling tools like stac_download_bands.

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 explicit guidance on when to use: 'Use this before large downloads to understand how much data will be transferred.' Tips for LLMs further instruct: 'Call this BEFORE large downloads to check feasibility' and recommend actions if estimated_mb > 500. It also mentions planning for stac_mosaic or stac_temporal_composite, offering context for 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the output format (JSON with matched pairs sorted by overlap percentage), notes that max_cloud_cover is ignored for non-optical collections, and explains the default values for collection, catalog, and output_mode. It lacks details on rate limits, authentication, or potential side effects, but these are not critical for a read-only search 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 well-organized with clear sections (main description, Args, Returns, Tips for LLMs, Example). It is concise yet comprehensive, front-loading the purpose and use case. Every sentence adds value, and the 'Tips for LLMs' section is particularly useful without being verbose.

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 7 parameters (3 required), no output schema, and no annotations, the description provides complete context: parameter explanations, output format, practical use-case guidance, and an example. It adequately prepares an agent to use the tool correctly in a change detection workflow.

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 description coverage is 0%, yet the 'Args' section in the description provides detailed explanations for every parameter: bbox format, date format for ranges, collection options, max_cloud_cover range and behavior, catalog options, and output_mode options. It also includes the default for max_cloud_cover and clarifies that it is ignored for non-optical collections. This adds substantial meaning beyond the raw 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 defines the tool's purpose: 'Find before/after scene pairs for change detection.' It explains the mechanism (searches two date ranges, matches by spatial overlap) and gives concrete use cases (flood damage, urban growth, deforestation, seasonal vegetation change). This clearly distinguishes it from sibling tools like stac_search or stac_compute_index.

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 'Tips for LLMs' section provides explicit guidance on when to use the tool (change detection workflows) and offers specific use-case recipes (flood mapping with sentinel-1-grd, vegetation change with sentinel-2-l2a). It also suggests follow-up tools (stac_download_bands, stac_compute_index). However, it does not explicitly state when not to use this tool or mention alternative tools for non-change-detection needs.

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, the description carries full burden. It explains that the file is saved locally and returns metadata, but does not specify cleanup or potential side effects. Still, it provides sufficient behavioral context for safe invocation.

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 well-structured: summary, args, returns, tips, example. It is somewhat lengthy but every sentence contributes value. Concise enough for a tool with two parameters.

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, the description fully describes return values (file_path, mime type, size, metadata) and provides an example. Both parameters are explained. Completeness is high for this tool's complexity.

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 0%, so the description must compensate. It explains artifact_ref as 'Artifact ID from a previous download tool call' and distinguishes between preview_ref and artifact_ref. output_mode is mentioned with defaults. This adds significant meaning 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 purpose: 'Retrieve a stored artifact and save it as a local file for viewing.' It specifies the verb (retrieve/save) and resource (artifact), distinguishing it from sibling tools that handle downloads of bands or composites.

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 'Tips for LLMs' section provides guidance on when to use preview_ref vs artifact_ref, and mentions the file is saved to a temporary directory. However, it lacks explicit exclusion criteria or comparison with alternative tools, so it's not a perfect 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?

With no annotations, the description carries full burden. It explains the internal behavior (reads conformance URIs, matches against known classes) and return format (JSON with flags and raw URIs). It implies a read-only, non-destructive operation, which is accurately disclosed.

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 approximately 100 words, well-structured with sections (main, Args, Returns, Tips, Example). Each sentence serves a purpose—no redundancy. It is concise yet 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?

Given no annotations, no output schema, and 2 parameters, the description is remarkably complete: it covers purpose, parameters, return value, usage guidance, and provides an example. Missing details like error handling are minor; overall, it enables correct invocation.

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 0%, but the description fully compensates. It enumerates allowed values for 'catalog' ('earth_search', 'planetary_computer', 'usgs'), default for 'output_mode' ('json'), and options ('text'). This adds meaning beyond the empty 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 checks which STAC API features a catalog supports, using a specific verb ('check') and resource ('catalog's conformance URIs'). It distinguishes from sibling tools like stac_capabilities and stac_search by focusing on feature support detection.

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 'Tips for LLMs' section explicitly states it's 'Rarely needed' and provides specific use cases (debugging, checking query support), guiding when to use and when not to. This is explicit guidance beyond typical descriptions.

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, but the description fully discloses that it is a read-only list operation returning JSON with catalog names and URLs. No hidden side effects or contradictions.

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 well-structured with Args, Returns, Tips, and Example sections. While slightly wordy, all content is relevant and 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?

Given no output schema and simple functionality, the description sufficiently explains the return format (JSON with catalog names and endpoint URLs) and provides usage examples, making it complete.

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 only parameter 'output_mode' is well described with allowed values ('json' or 'text') and default, compensating for the lack of schema descriptions (0% coverage).

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 lists all known STAC catalogs and returns pre-configured endpoints. It distinguishes itself from sibling tools like stac_capabilities by noting that stac_capabilities provides a fuller overview.

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 advises to use stac_capabilities for a full overview, mentions default catalog and auto-authentication for planetary_computer, giving clear context for when to use this tool vs 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?

No annotations provided, so the description carries full burden. It states it queries the live API (read-only), but does not mention authentication, rate limits, or error handling. Disclosure is adequate but could be more comprehensive.

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 well-structured: short purpose, clear sections for args/returns/tips, and an example. Every sentence adds value without 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 listing tool with no output schema, the description covers input parameters, return format (JSON list with titles, descriptions, extents), and usage context. It is complete given the tool's simplicity.

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% but the description's Args section adds default values, options, and explanations for both parameters, providing significant meaning beyond the raw 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 'List available collections in a STAC catalog', specifying the verb and resource. It differentiates from sibling tools by explicitly mentioning follow-up with stac_describe_collection for detailed info.

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 when-to-use guidance ('discover what data is available'), alternative catalogs, and a related tool for deeper detail (stac_describe_collection). Also suggests trying other catalogs if a collection is not found.

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?

The description adds behavioral context beyond the readOnlyHint annotation by detailing the map's visual elements (polygons, grouping, popup content). It confirms the tool is read-only and visual, consistent with the annotation.

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 efficiently convey purpose, visual output, and usage prerequisite. No redundant information, but could briefly mention the basemap parameter for completeness without adding much length.

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 2 parameters and no output schema, the description covers the main use case and prerequisite. However, it omits the basemap parameter and scene_ids format, leaving gaps for an agent to fully invoke the tool correctly.

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?

With 0% schema description coverage, the description should compensate. It mentions scene_ids and how to pass them ('pass the scene_ids here') but does not explain the format (e.g., comma-separated or array) nor the basemap parameter. This leaves ambiguity for the agent.

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 visualizes STAC scene search results as a multi-layer footprint map, specifying what appears (bounding-box polygons grouped by collection) and details in popups. This distinguishes it from sibling tools like stac_mosaic or stac_pairs_map.

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 instructs to run stac_search first and then pass scene_ids, providing a clear prerequisite and usage flow. It implies when to use this tool (after a search) but does not explicitly state when not to use 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?

With no annotations, the description fully discloses behavior: combines scenes, defaults (bbox union, method='last'), Sentinel-2 limitations for cloud_mask and quality method, and output format. Discloses that output is JSON with artifact_ref.

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?

Well-structured with intro, parameter list, tips, and example. All sentences add value, but parameter explanations are slightly verbose. Still appropriate for the complexity.

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?

Covers all 7 parameters, required and optional, explains behavior, provides usage guidelines, tips, and an example. Output format is described. Complete for a tool with no annotations or output schema.

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 tool description explains every parameter in detail, including defaults and usage examples. Completely compensates for missing schema descriptions.

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 'Create a mosaic from multiple scenes' and explains it combines overlapping scenes into a seamless raster. It distinguishes from siblings like stac_temporal_composite by specifying it's for when area spans multiple tiles.

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?

Includes explicit 'Tips for LLMs' that advise using stac_coverage_check first, choosing method='quality' for cloud-free mosaics, and redirecting to stac_temporal_composite for temporal compositing. Provides clear when-to-use and 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?

Annotations already declare readOnlyHint=true, indicating no side effects. The description adds behavioral detail: it renders a two-layer map with toggling capability for comparing coverage. This goes beyond the annotation by specifying visual behavior and interaction, without contradicting the read-only 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 exceptionally concise with two sentences, front-loading the core purpose and key details (colors, layer toggling). Every word adds value, no 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?

Given the tool's low complexity (visualization only), the description is largely complete for an agent to understand its role and basic usage. It could be improved by noting parameter formats (e.g., comma-separated IDs) or the basemap default, but such details are secondary for map generation purposes.

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?

With 0% schema description coverage, the description must compensate. It indirectly explains that before_scene_ids and after_scene_ids come from stac_find_pairs, but does not describe valid formats, constraints, or the basemap parameter's possible values. The meaning is partially inferred from the tool name and context, but explicit parameter guidance is missing.

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 visualizes before/after scene pairs from stac_find_pairs as a two-layer map with specific colors (blue=before, red=after) and action (toggle layers to compare). This specific verb+resource combination distinguishes it from siblings like stac_map (general map) and stac_find_pairs (search).

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 usage after stac_find_pairs by referencing scene pairs from that tool. It explains the map's purpose and layer comparison, providing clear context. However, it does not explicitly state when not to use it or mention alternatives, though the sibling tools are listed elsewhere.

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, the description carries full burden. It discloses the return format (preview_url), response modes (json/text), and that not all scenes have thumbnails. It is transparent about the operation being a quick preview, but could mention potential failure mode details (e.g., network issues).

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 well-structured with intro, details, tips, and example. Each sentence is informative; no waste. Slightly verbose but justified by the tips section. Front-loaded with purpose.

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 2 parameters, no output schema, and many siblings, the description is complete: explains prerequisites, return values, and usage limitations. It covers all necessary context for an AI agent to use the tool effectively.

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 0%, but the description fully explains both parameters: scene_id as from stac_search, output_mode with default and options. It provides an example, adding semantic clarity well beyond the bare 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 retrieves a preview/thumbnail URL for a scene, distinguishing it from siblings like stac_download_bands (full band download) and stac_search (scene discovery). It emphasizes speed advantage, giving a specific verb+resource purpose.

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 notes the scene must come from a prior stac_search call, and advises using it for quick visual checks before full downloads. Tips mention checking for errors if no thumbnail exists, providing clear when-to-use and when-not-to-use 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?

The description explains the return format and behavior (e.g., different catalogs support different properties) but does not explicitly mention that the tool is read-only or any side effects. However, the overall 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.

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

The description is well-structured with sections for purpose, args, returns, tips, and an example. It is concise and front-loaded with the most important information.

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?

All relevant context is provided: purpose, parameters, return value, usage tips, and an example. No output schema exists, but the description covers the necessary details.

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?

Despite 0% schema description coverage, the description fully explains each parameter: catalog options, collection example, and output_mode formats. This compensates entirely for the missing schema descriptions.

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 'Fetch queryable properties from a STAC API' and explains the return value, distinguishing it from sibling tools like stac_search which handles actual searches.

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 'Tips for LLMs' section explicitly states when to use this tool ('rarely needed', 'useful when debugging') and names stac_search as an alternative, providing clear usage 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?

Despite no annotations, the description transparently discloses key behaviors: results are cached for follow-up operations, return format is JSON sorted by cloud cover or date, and hints field is provided for troubleshooting. It also specifies when parameters are ignored and the default catalog/collection. No contradictions.

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 well-structured with a brief summary, numbered arguments, returns, tips, and an example. It is front-loaded with the purpose, and every sentence adds value. While lengthy, it is not verbose given the complexity.

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 complexity (7 parameters, no output schema, 23 sibling tools), the description is complete: it covers all parameter details, edge cases (e.g., omit date_range for cop-dem-glo-30), typical workflow, caching, and troubleshooting hints. It provides sufficient context for an AI agent to effectively use the 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?

With 0% schema description coverage, the description compensates fully by providing detailed semantics for all 7 parameters: bbox format with example, collection options with resolution and bands, date_range format, max_cloud_cover defaults and exceptions, max_items default, catalog options, and output_mode. It also includes tips and examples.

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 'Search for satellite scenes matching spatial and temporal criteria' and identifies it as 'the primary entry point for finding satellite imagery'. This distinguishes it from siblings like stac_describe_scene and stac_download_bands, which are follow-up operations.

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 provides a typical workflow (stac_search → stac_describe_scene → stac_download_bands), offers tips for specific use cases (e.g., flood mapping, vegetation analysis), and advises when to adjust parameters (e.g., increase max_cloud_cover for cloudy regions, use sentinel-1-grd for SAR). It also notes when certain parameters are ignored (e.g., max_cloud_cover for non-optical collections) and suggests alternatives if zero results.

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 full burden. It describes return values (version, storage provider, default catalog) and hints at behavior (check artifact_store_available). However, it does not explicitly state that the operation is read-only or safe.

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?

Well-structured with clear sections (Args, Returns, Tips, Example). Every sentence adds value, and the total length is appropriate for the tool's complexity.

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 status tool with no output schema, the description adequately explains return values and includes a usage tip. It could mention error handling or the 'text' output format behavior, but overall is sufficiently complete.

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 one parameter (output_mode) with type and default but no description. The description does not explain the parameter's allowed values or impact on output format, nor does it describe any other parameter aspects. Despite 0% schema coverage, the description fails to compensate.

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 explicitly states 'Get server status and configuration' and lists the returned information, clearly distinguishing it from siblings by directing users to stac_capabilities for workflow planning.

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 this to verify the server is running and check storage configuration.' Also includes tips for when to use alternatives (stac_capabilities) and when to check artifact_store_available before downloads.

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?

Since no annotations are provided, the description carries the full burden. It explains the compositing workflow, automatic cloud filter skipping for non-optical collections, and default values. However, it does not mention whether the tool is read-only or has any side effects, which would be helpful.

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 well-structured with purpose, process, Args, Returns, Tips, and Example sections. It is front-loaded with the main purpose. While somewhat lengthy, every sentence adds value and the structure aids readability.

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's complexity (11 parameters, no output schema, no annotations), the description provides thorough coverage: explains output format, gives example usage, and offers practical tips. It could be more explicit about error handling, but overall it is complete.

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?

With 0% schema coverage, the description fully compensates by documenting all 11 parameters in the Args section, including formats (bbox, date_range), defaults (method, max_items), and domain knowledge (e.g., method options with guidance, cloud_mask rationale).

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 starts with a clear statement: 'Create a temporal composite by combining multiple scenes statistically.' It explains the process of searching, downloading, and combining scenes, and distinguishes itself from sibling tool stac_time_series for per-date outputs.

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 explicit guidance on when to use this tool ('creating cloud-free composites from cloudy time series') and when not to ('For per-date outputs instead of a single composite, use stac_time_series'). It includes detailed tips for method selection and enables cloud_mask for best results.

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 bears full responsibility. It describes the search and download process, notes that cloud cover filtering is skipped for non-optical collections, and implies read-only behavior. Some details like error handling or performance guarantees are missing, but overall it is thorough.

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 relatively long but well-structured with sections (Args, Returns, Tips, Example). The main purpose is front-loaded, and each sentence contributes value. Minor redundancy in tips (e.g., repeating max_items explanation) could be trimmed, but still 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 the complexity (8 parameters, no output schema, no annotations), the description is complete. It covers the tool's operation, usage constraints, return format, and includes a realistic example. No critical 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 0%, but the description includes a detailed 'Args' section and 'Tips' that explain each parameter's purpose, default values, and behavior (e.g., max_cloud_cover 0-100, default 20). This adds significant meaning beyond the bare 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 'Extract a time series of band data over an area,' which is a specific verb and resource. It distinguishes from siblings like stac_temporal_composite, which produces a single composite 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 provides explicit guidance on when to use this tool (monitoring change over time) and when not to (single cloud-free image, recommending stac_temporal_composite). It also includes tips on bbox size, cloud cover, and max_items.

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 full burden. It discloses return of per-zone statistics and optional z-score anomaly detection, explains the logic, and notes the raster must be a GeoTIFF. Side effects and auth are not mentioned, but the read-only nature is implied.

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 well-structured with a summary, zone explanation, anomaly section, and parameter list. It is front-loaded with purpose. While long, every sentence adds value. Minor redundancy in zone explanation 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?

With 10 parameters, no output schema, and no annotations, the description covers all parameters, return values, and usage context. It mentions projection requirements and anomaly detection logic. Lack of explicit return format is compensated by clear per-zone statistics mention.

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 0%, so description compensates fully. Each parameter is explained: points format, buffer_m meaning, geojson types, zones_crs examples, background_m enabling anomaly detection, etc. This adds substantial meaning beyond the schema types.

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 reads raster values within zones, specifying it as the inference step after fetch. It distinguishes between buffer and polygon zones and gives concrete examples (NDVI index, GeoTIFF). This is specific and differentiates from sibling 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 provides clear context on when to use (after fetch, with stored raster artifacts) and explains two zone input modes. It implicitly excludes PNG previews and gives anomaly detection use case. While it doesn't explicitly name alternatives, the context makes usage clear.

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