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

Goes well beyond the annotations by disclosing the scene-selection rule (most recent Sentinel-2 scene within days_back with ≥60% clear) and the hard 25 km² area cap. It doesn't say what happens when no scene meets the 60% threshold, which is the main residual gap.

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?

A single dense sentence with no wasted clauses: the output content, the area limit, and the scene-selection criteria are all front-loaded and each phrase 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?

With no output schema, the description does its job by enumerating the returned metrics and their temporal basis. Minor gaps remain on units (elevation/slope) and the shape of the land-cover shares, but an agent can call this 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 must carry the parameters. It does specify the bbox ordering as [west, south, east, north] and the days_back range 15–365, which is genuinely useful, but it omits the bbox coordinate units (presumably degrees) and doesn't restate the default of 90.

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 composite deliverable — land-cover shares, elevation/slope stats, and NDVI — for a bounded box, so the agent knows exactly what it gets back. It doesn't explicitly contrast itself with the sibling tools (land_cover, elevation, ndvi_timeseries), though the word 'Quick report' and the area cap imply the composite route.

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 25 km² maximum and the days_back range imply when the tool is appropriate (small areas, recent imagery), but the description never says when to prefer it over the sibling layers or what to do for larger areas. Usage is implied 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?

Annotations already establish the read-only, idempotent, open-world safety profile, so the description's job is to add semantics — and it does: units (metres, EGM2008 vertical datum), slope derivation method (Horn 3x3 on a 30 m grid), and the 150 m relief window. It doesn't state what happens near coast/nodata cells, but the methodological detail exceeds what the annotations supply.

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?

A single tight sentence that front-loads the data source and unit, then appends the derived quantities with their algorithms in parentheses. No filler, 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?

With no output schema and no parameter descriptions, the description carries the burden of explaining returns, and it does so explicitly (elevation value, slope in degrees, local relief). Only the coordinate convention and edge-case behavior (nodata, ocean) are unaddressed.

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 would ideally clarify coordinate conventions. It implies 'at a point' but never states the expected CRS (presumably WGS84 degrees), nor any bounds; however, lon/lat are self-explanatory names and the omission is low-risk.

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 names the specific product (Copernicus DEM GLO-30) and precisely enumerates the three returned quantities: point elevation, slope, and local relief. That is far more specific than a restatement of the name, though no sibling (e.g. area_summary, which could plausibly overlap) is named to delimit 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?

There is no statement of when to use this tool versus alternatives, no prerequisites, and none of the siblings (area_summary, land_cover) are referenced. The agent must infer from the description alone that this is the point-query counterpart to area-level tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive, so the safety profile is covered. The description adds genuinely new context: dataset identity/version, spatial resolution, the class-code encoding, and the max 500 m buffer cap. It does not address no-data/ocean handling, which keeps it at 4 rather than 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?

Two sentences, no filler, with the core purpose and result encoding front-loaded ahead of the optional-buffer behavior. Every clause carries 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?

With no output schema, the description does explain returns: a class code at the point, and per-class percent shares when buffer_m > 0. It stops short of describing the shape of the buffered result and leaves coordinate format to inference, so it is strong but not fully self-sufficient for a three-parameter geo tool.

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

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

Schema description coverage is 0%, so the description must carry all parameter meaning. It explains buffer_m well (values > 0 add per-class percent shares, capped at 500) but says nothing about lat/lon units, ordering, or valid ranges. It compensates for only one of three undocumented 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?

States a specific resource with provenance and granularity: 'ESA WorldCover 2021 (10 m) land-cover class at a point,' plus a concrete example of the returned encoding (40 = Cropland). That is unmistakably distinct from elevation, ndvi_timeseries, or search_imagery without opening any schema.

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 only implied by 'at a point' and by the buffer_m clause describing the extra output. There is no explicit statement of when to prefer this over a sibling like area_summary or elevation, and no exclusions or prerequisites.

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?

Goes well beyond the readOnly/idempotent/openWorld annotations: it describes pixel averaging at 10 m, SCL-based cloud/shadow/cirrus masking, that fully cloudy dates are skipped and listed, that max_scene_cloud is a pre-filter, and the exact thresholds behind the low_confidence and suspect_dip flags. The 2-year refusal limit is also disclosed, so an agent knows the hard failure mode before calling.

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?

Front-loads what is measured and where, then layers masking behavior, output fields and limits in a compact multi-sentence block with no filler. Given there is no output schema, the enumeration of per-date fields earns its space.

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

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

With no output schema, the description correctly compensates by listing per-date fields (ndvi_mean, ndvi_std, clear_pixels, clear_fraction, item_ids, flags) and by explaining skipped cloudy dates. The overall response envelope (how the per-date list and the skipped-date list are packaged) and NDVI value units/scale are not spelled out, which is the only remaining gap.

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 carry the load, and it does for most parameters: start/end format (YYYY-MM-DD), buffer_m with its 0-500 range, and max_scene_cloud as a scene-level percentage pre-filter. lat/lon are left implied, which is acceptable given they are self-evident, but the missing explicit CRS/units note keeps this from a 5.

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+resource+scope: Sentinel-2 L2A NDVI at a point for every usable scene in a date range. It is clearly distinct from siblings like search_imagery, land_cover and elevation, since it returns a per-date NDVI series rather than imagery, classes or terrain.

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?

Gives clear operating context: single point with a buffer, per-scene cadence, and an explicit constraint that ranges longer than 2 years are refused. It does not, however, name alternatives (e.g., when to use search_imagery instead) or state prerequisites like whether the point must be over land.

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 annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond that: results are newest first, and the return includes scene IDs, acquisition times, cloud cover, tile, and sources/checks/notes.

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 compact and front-loaded: it states the main action first, then spatial input, dates, collection, cloud/limit, and return fields. Every sentence adds useful information without repetition.

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

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

With no output schema, the description usefully states what is returned and in what order. It also covers the key spatial and temporal parameters. Minor omissions such as explicit defaults, required-field restatement, or error behavior are already covered by the schema or are not critical for a read-only search tool.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does: bbox order and WGS84 units, point lon/lat, YYYY-MM-DD inclusive dates, allowed collection values, max_cloud as scene-level percent, and limit range 1-50. This meaningfully documents all eight parameters even though defaults and required fields remain visible in 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 gives a specific verb and resource: list satellite scenes covering a place and date range. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as ndvi_timeseries, land_cover, or elevation.

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 search/list framing and the 'newest first' ordering, but there is no explicit guidance on when to choose this tool over the sibling analysis tools or when not to use it. The description explains invocation shape more than selection criteria.

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 the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description correctly spends its words elsewhere: it discloses that computation is done 'directly from the raw bands on the scene's native grid' and that it returns pass/warn/fail with per-check detail. It omits cost/latency expectations for raster reads and what happens when no clear scene exists in the window.

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 front-loaded sentences with no filler; the purpose and the three checks are stated before the return contract. Dense but every clause carries information, though the middle sentence packs multiple checks into one long clause.

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 the description supplies the return contract (pass/warn/fail plus per-check detail) and names all three checks. Remaining gaps — coordinate conventions, behavior when no clear scene is found, and cost — keep it short of complete for a comparison tool that touches multiple raster products.

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 does explain `days_back` well ('latest clear scene (last days_back days)') and implies lat/lon via 'at a point', but says nothing about coordinate order, CRS, or the default of 120 days — so compensation is only partial.

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 — 'independent sanity checks at a point' — and enumerates exactly what is checked: NDVI recomputed from raw B04/B08/SCL bands vs. the ndvi_timeseries pipeline, native vs. regridded elevation and land cover, and land cover vs. NDVI. This clearly distinguishes it from the sibling generation tools (ndvi_timeseries, land_cover, elevation) by framing it as a cross-validation step.

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 only implied: the phrase 'independent sanity checks' and the explicit comparison with the ndvi_timeseries pipeline suggest it should be used after those products exist, but there is no explicit when-to-use/when-not statement or named alternative. An agent must infer the trigger condition.

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