Skip to main content
Glama

search_imagery

Destructive

Search satellite imagery catalogs for scenes over a location and date window, filtering by cloud cover and event coverage to find usable pre/post-event imagery.

Instructions

Search the satellite imagery catalog (Sentinel-1/2, OPERA RTC-S1) for scenes over an area and date window — the natural follow-up to a signal (find imagery over the event location). Returns scene metadata (id, datetime, footprint, cloud cover, platform, orbit geometry, coverage, catalog link) — no imagery bytes. Pass eventDate to classify each scene timing=pre/post/same_day_unknown (a same-day scene is same_day_unknown, never post, without a real event time) and get pre/post bracketing + window_status + SAR sar_pair_status in meta. Pass eventPoint [lon,lat] and/or eventAoi [minLon,minLat,maxLon,maxLat] to get each scene's target_relation (covers_event_geometry = pure geometry gate; usable_for_analysis additionally requires acceptable cloud for optical, so a 99%-cloud scene is geometry-covering but not analysis-usable) — so a scene that only clips the wide bbox is not mistaken for covering the event. Costs 2 token(s) per call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bboxYesBounding box [minLon, minLat, maxLon, maxLat] (WGS84). Required.
dateNoWindow end date, YYYY-MM-DD (UTC). Defaults to today.
daysNoWindow length in days. Defaults to 7.
limitNoMax scenes to return. Defaults to 25.
eventAoiNoEvent AOI bbox [minLon, minLat, maxLon, maxLat] (WGS84). Drives target_relation.intersects_event_aoi / event_aoi_coverage_ratio.
eventDateNoEvent date, YYYY-MM-DD (UTC). When set, each scene is tagged timing=pre/post/same_day_unknown and the search window is widened to the canonical pre/post span, so meta reports has_pre_baseline / has_post / bracketing_available / window_status; for sentinel-1-grd it also reports sar_pair_status (ready | not_ready | indeterminate_event_time) + orbit_note.
collectionNoCatalog collection. Defaults to sentinel-2-l2a.
eventPointNoEvent point [lon, lat] (WGS84). When set, each scene reports target_relation.covers_event_point / usable_for_event so a scene that only clips the wide bbox is not presented as covering the event.
cloudCoverMaxNoSentinel-2 only: max cloud cover %.
eventTimestampNoFull event timestamp (ISO 8601) when known — promotes same-day scenes from same_day_unknown to pre/post by time.
responseFormatNoPer-scene field detail. "concise" (default) returns id, collection, datetime, timing, cloud_cover, platform, orbit_state, relative_orbit, instrument_mode, product_type, coverage_ratio, covers_event_point, usable_for_event, stac_item_url, preview. "detailed" adds the full footprint bbox/geometry, the complete target_relation, constellation, polarizations, absolute_orbit, incidence_angle, and non-signed asset hrefs.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
metaYesQuery echo, token charge/balance (meta.tokens), and pagination where applicable.
scenesYes
summaryNoOne-line natural-language summary of the result, ready to relay to a user.
Behavior1/5

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

The annotations include destructiveHint: true, but the description clearly indicates a read-only search operation returning metadata with no imagery bytes. This directly contradicts the destructive hint. While the description is rich in behavioral detail, the contradiction mandates a score of 1 per the scoring rules.

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?

Though lengthy, every sentence delivers critical operational detail: catalog scope, output type, parameter effects, edge-case clarifications, and cost. The structure front-loads the core purpose and methodically explains optional parameters, avoiding redundancy with the input schema.

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

Completeness5/5

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, multiple collections, nuanced target_relation logic), the description is exceptionally complete. It covers what is returned, how to interpret derived fields, when to use eventDate/eventPoint/eventAoi, and even cost. The presence of an output schema reduces the need to explain returns, but the description adds value by explaining semantics, not just listing fields.

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

Parameters5/5

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

The description adds rich semantics beyond the schema, especially for eventDate (timing classification, pre/post bracketing, SAR pair status) and eventPoint/eventAoi (target_relation with geometry gate vs. usability gate). It clarifies edge cases like same-day scenes without eventTimestamp and cloud-cover thresholds, far exceeding baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'Search the satellite imagery catalog' with specific collections (Sentinel-1/2, OPERA RTC-S1) and scope (area and date window). It also positions it relative to siblings by calling it 'the natural follow-up to a signal (find imagery over the event location)', making it distinct from related tools like plan_event_imagery or query_signals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides a use case: 'natural follow-up to a signal (find imagery over the event location)'. It also indicates what the tool does NOT do ('no imagery bytes'), implicitly guiding agents to choose another tool if they need actual imagery. This clear context and implicit alternatives qualify as strong usage guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Off-Nadir-Lab/offnadir-delta-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server