Skip to main content
Glama

search_scenes

Read-onlyIdempotent

Find satellite scenes intersecting a bounding box and date range, filtered by cloud cover, returning IDs, dates, footprints, and preview links for STAC catalog exploration.

Instructions

Search scenes intersecting a bbox in a date range, newest first.

Returns id, date, cloud cover, a simplified footprint and a preview image link. Cloud cover is for the whole tile, not the bbox.

Input Schema

NameRequiredDescriptionDefault
bboxYes[west, south, east, north] in WGS84 degrees, e.g. [12.47, 41.9, 12.5, 41.92]
limitNoMaximum scenes to return (1-50)
catalogNoSTAC catalog. Defaults to the server's configured catalog.
collectionYesCollection id, e.g. 'sentinel-2-l2a' (alias 'sentinel-2' works)
date_rangeYesISO interval 'YYYY-MM-DD/YYYY-MM-DD', e.g. '2025-04-01/2025-09-30'
max_cloud_coverNoMaximum scene cloud cover in percent (0-100). Omit for no filter.

Output Schema

NameRequiredDescriptionDefault
scenesYes
catalogYes
returnedYes
collectionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.