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

Adds real behavioral detail beyond the annotations: cloud/shadow/no-data masking via SCL, an area cap (default 100 km²), and an explicit statement that no raster data is returned unless save is set. The annotations already cover read-only/destructive/idempotency semantics, though the description does not mention open-world or rate/permission behavior.

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 sentences, front-loaded with what is computed, followed by masking, return shape, and the area constraint. 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?

With an output schema present and annotations covering safety semantics, the key gaps an agent needs (masking behavior, returned statistics, no-raster default, area cap) are all covered. Only edge behavior such as failure modes when the bbox exceeds the area limit or the scene lacks SCL is left implicit.

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%, so the baseline is 3; the description still adds value by tying bbox to a window-only read, tying save to returned file paths, and flagging the area limit that constrains bbox size. It does not add detail the schema lacks for catalog or index enums, which is fine.

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?

States a specific verb (compute) and resource (spectral index over a Sentinel-2 L2A scene) and names the concrete outputs (NDVI, NDWI, NBR). It also pins the scope to a bbox window and a single scene, which cleanly separates it from siblings like search_scenes and time_series.

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?

Implies the prerequisite chain by saying item_id comes from search_scenes and that only one scene is processed, which steers an agent away from using it for multi-scene or series work. It does not explicitly name time_series as the alternative for multi-date analysis or 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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so safety behavior is covered. The description adds that the result includes metadata and asset types (bands, previews, metadata files), which is useful context beyond annotations, but it does not add deeper behavioral details such as auth requirements 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 a single front-loaded sentence with no wasted words, immediately stating the core content and scope. It is appropriately sized for a simple detail-fetch tool.

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 an output schema, full parameter descriptions, and read-only/idempotent annotations, the description provides enough context for an agent to understand what the tool returns. The main incomplete area is the lack of explicit routing guidance versus sibling tools.

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 all three parameters are already documented in the schema, including defaults and meanings. The description adds no parameter-specific syntax or semantic detail beyond what the schema provides, so baseline 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 it returns metadata and asset lists for a single scene, which is a specific resource and output scope. It does not explicitly distinguish itself from sibling tools like search_scenes, but the singular 'one scene' implies the distinction.

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?

There is no explicit guidance on when to use this tool versus search_scenes or list_collections, nor are prerequisites or exclusions stated. Usage must be inferred from the phrase 'of one scene' and the schema's note that item_id comes from search_scenes.

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 cover safety (readOnlyHint, idempotentHint) and scope (openWorldHint), so the description only needs to add workflow context. It does: the result is a lightweight id + one-sentence-description listing, and those ids are the canonical input for sibling tools — useful planning information not present in annotations. It omits any mention of network/catalog-specific caveats or result size.

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 short sentences, purpose first, chaining guidance second — every clause earns its place with no repetition of schema or annotation content.

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 one-parameter, optional-argument, output-schema-backed read tool with annotations, the description supplies purpose and the downstream workflow, which is the main thing an agent needs. The only gap is that it doesn't hint at catalog selection behavior, which the schema covers adequately.

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% and the single `catalog` parameter is fully documented with an enum and a default-behavior note. The description never mentions the catalog parameter, so it adds nothing beyond the schema; baseline 3 applies.

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?

States a specific verb and resource ('List the collections available in a STAC catalog') plus what each entry contains ('a one-sentence description'). The second sentence ties the output ids to specific sibling tools, so an agent can immediately distinguish this discovery tool from search_scenes and get_scene_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 tells the agent what to do with the result ('Use the returned ids as `collection` in search_scenes and get_scene_details'), which effectively establishes this as the discovery step before searching or fetching details. It stops short of any exclusion, e.g. when to skip listing and search directly, or how to choose between the two catalogs.

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 cover read-only, idempotent, and open-world behavior, so the bar is lower. The description still adds real context beyond them: result ordering (newest first), the shape of returned records, and the important caveat that cloud cover applies to the whole tile rather than the bbox — a non-obvious semantic detail an agent would otherwise get wrong.

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 sentences, front-loaded with the core operation, then return shape, then the one caveat that matters. No restated parameter definitions and 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?

For a 6-parameter search with annotations and an output schema, the description covers scope, ordering, and the cloud-cover caveat. It omits what happens on an empty result and any pagination/limit behavior, but nothing essential to a correct first call is missing.

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%, so baseline is 3; the description earns above that by clarifying that max_cloud_cover is a tile-level property that does not mean mask-free pixels over the requested bbox, which the schema text does not convey. It adds nothing about limit or catalog, which remain schema-only.

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?

States a specific verb and resource ('search scenes') with the two key scoping axes (bbox, date range) and an ordering guarantee ('newest first'). It does not name any sibling to distinguish itself from, so it falls short of the 5 tier, but an agent can still tell this apart from get_scene_details or list_collections by the resource and scope.

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 bbox+date-range framing implies the search use case, but there is no explicit when-to-use/when-not guidance and no reference to alternatives like get_scene_details for a single known scene or list_collections for discovering collections. Usage is inferable rather than stated.

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?

Adds substantial context beyond the annotations: one scene per day, cloudy dates dropped with a reason, even sampling when dates exceed the server limit (default 24), and a 10-60 s latency expectation. Only the response's concrete field structure and failure modes are left unspecified, and an output schema exists.

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 compact sentences, with the core definition front-loaded and the operational caveats (sampling limit, latency) following. No filler, though the sampling sentence is dense enough to require a second read.

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 read-only, open-world tool with a full output schema, the description covers everything an agent needs to decide and set expectations: temporal granularity, cloudy-date handling, result-count capping, and runtime. Return-value details are correctly deferred to the 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 100%, so bbox, index, catalog, date_range and max_cloud_cover are already documented, establishing a baseline of 3. The description adds only indirect meaning (cloudy dates are skipped, so max_cloud_cover affects sample count) and never explains the dates-sampling parameter interaction.

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?

States a specific verb (mean of an index) over concrete resources (bbox, Sentinel-2 acquisition dates) with temporal scope, which cleanly separates it from compute_index (single computation) and search_scenes (scene listing). The output shape ('mean ... for each date') is stated in the first line.

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?

Usage is implied by the stated output shape – an agent can infer 'use this when you need a temporal profile rather than one value' – but no alternative tool (compute_index, search_scenes) is named and no exclusions or prerequisites are given. The reader must infer when-to-use from siblings.

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