Skip to main content
Glama

predict_satellite_passes

Destructive

Predict when satellites can next image any location. Returns pass times, off-nadir angles, and sunlit conditions for free and taskable commercial sensors to plan collection.

Instructions

WHEN can this place next be imaged, and by WHAT — the timing half of collection planning. Propagates current orbital elements (SGP4 over day-cached CelesTrak two-line elements) for seven families and returns the access windows over a target: Sentinel-1 (SAR), Sentinel-2 and Landsat (free, SYSTEMATIC — routinely collected, so near-certain), plus WorldView, ICEYE, Capella and SkySat (commercial, AGILE — taskable ACCESS opportunities that require a paid order and are NOT guaranteed collects). Each pass carries acquisition/loss times, the closest-approach instant, peak elevation, OFF-NADIR angle, ground distance, ascending/descending, solar elevation and whether the target is sunlit (optical needs light; SAR does not), and the age of the element set it was computed from. Use it to answer "when is the next chance to see this", to choose between waiting for a free systematic pass and paying to task an agile one, and to time a pre/post change-detection pair. Give lat/lon, or a bbox whose centre is used. Horizon is capped at 7 days. If elements cannot be retrieved the result says so (retrieval_ok:false) — that means timing is UNAVAILABLE, never "no passes". Every pass is a GEOMETRIC access opportunity computed from orbital elements and swath width (geometry_only:true, acquisition_plan_verified:false): no operator collection plan is consulted, so this is when a sensor COULD see the target, never a confirmed acquisition schedule. With no start_date the window begins NOW, so the first pass listed is always still ahead. Costs 2 token(s) per call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNoTarget latitude (-90..90; positive = North). Required unless bbox is given.
lonNoTarget longitude (-180..180; positive = East). Required unless bbox is given.
bboxNoArea [west, south, east, north] in WGS84. The CENTRE is used as the target when lat/lon are omitted.
end_dateNoInclusive end date YYYY-MM-DD (UTC). Defaults to start+2 days; the window is capped to a 7-day horizon.
max_passesNoMaximum passes to return, soonest first (default 40).
satellitesNoFamilies to consider. Omit for all seven. Use this to compare "free systematic only" against "what could I task".
start_dateNoInclusive start date YYYY-MM-DD (UTC). Defaults to today.

Output Schema

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

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

The description richly discloses behavior (SGP4 propagation, token cost, retrieval_ok:false semantics, geometry_only:true, never confirmed acquisitions), but the annotations contain destructiveHint:true, implying the tool destroys or modifies something. The description describes a purely predictive/read-only operation, directly contradicting the annotation. Per rubric, this contradiction forces a score of 1.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The description is long but intentionally so, front-loaded with the core question. Every sentence adds operational value (method, uncertainty, error behavior, defaults). It could be tightened but is not bloated for the tool's complexity.

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, the description is exceptionally complete: it defines output semantics (pass attributes), failure modes (retrieval_ok:false), limitations (geometry only, never confirmed), horizon cap, defaults, and cost. The presence of an output schema further reduces the burden of explaining return values.

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 descriptions cover all 7 parameters (100% coverage), so baseline is 3. The description adds extra meaning: bbox's centre is used, satellites parameter groups free/systematic vs commercial/agile, and default behaviors for start_date and max_passes. This goes beyond the raw schema.

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 predicts satellite passes, opening with "WHEN can this place next be imaged, and by WHAT — the timing half of collection planning." It names the resource (satellite pass access windows) and distinguishes itself from siblings by focusing on future collection opportunities rather than existing imagery or analysis.

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

Usage Guidelines4/5

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

Explicitly tells when to use it: to answer "when is the next chance to see this", to choose between free systematic passes and paid agile tasking, and to time change-detection pairs. It also gives practical constraints (7-day horizon, retrieval failure meaning). However, it doesn't explicitly say when not to use it or name alternative sibling tools like search_imagery for past imagery.

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