Skip to main content
Glama

search_scenes

Search for satellite scenes over a specified area and date range, filtering by sensor or product, and see availability status (ready, archived, on-order, priced) to decide next steps.

Instructions

Search Bhoonidhi scenes for a satellite over an area and date range.

The satellite may be a casual name ("Sentinel-2", "cartosat"); it is matched to the portal's exact tokens, and a constellation expands to all its platforms. Dates are ISO (YYYY-MM-DD). Give the area either as a bounding box (minx/maxx/miny/maxy) or a point with radius (lat/lon/radius_km) — typically from resolve_location. sensor narrows to one sensor on the matched satellite(s) (e.g. "SSAR", "LISS3"); product further narrows to one product under that sensor (e.g. "GCOV", "L2C-Chlorophyll") — see list_archive for the exact sensor/product names each satellite carries. The search is stateless and needs no login.

If the satellite name is ambiguous, returns status="ambiguous_satellite" with candidate names instead of guessing.

Each scene carries an "availability": Ready (downloadable now), Archived (open data but may need a portal request first), OnOrder (must be requested), or Priced (must be purchased). The result includes a plain-English "summary" of these counts and a "how_to_act" block. Tell the user clearly when scenes are Archived, OnOrder, or Priced and what each needs. This search is stateless: to act on these scenes, call save_query with the same arguments to persist them and get a , then download_query (open data) or cart_add (on-order / priced) on that slug — both need a login (see auth_status). Downloads cannot be resumed if interrupted (the portal has no range support).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNo
lonNo
maxxNo
maxyNo
minxNo
minyNo
sensorNo
productNo
end_dateYes
radius_kmNo
satelliteYes
start_dateYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.2.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden, and it delivers: it discloses statelessness, no-login requirement, ambiguous-satellite behavior, availability categories (Ready/Archived/OnOrder/Priced), and the non-resumable download limitation. This is far beyond what the schema alone would communicate.

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 well-structured and front-loaded with the core purpose, then details. It is dense but justifiably so for a 12-parameter tool. Minor redundancy exists: 'stateless' is stated twice and the download-resume note is tangential to searching, so it loses a point.

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 no output schema and no annotations, this description covers all essential context: what the tool does, how to specify each kind of input, what the response classes mean, how to handle ambiguity, and exactly which sibling tools to call next. Very little is left for an agent to guess.

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?

Schema description coverage is 0%, but the description compensates thoroughly: it explains satellite name matching, ISO date format, the bbox vs. point-with-radius area alternatives, and how sensor/product narrow results. It meaningfully clarifies nearly every parameter group in the 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 opens with a specific verb and resource: 'Search Bhoonidhi scenes for a satellite over an area and date range.' It clearly describes the scope and outputs, and distinguishes itself from downstream persistence/action siblings by explicitly framing the search as stateless.

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?

The description gives strong routing guidance: use resolve_location for area input, list_archive for exact sensor/product names, and save_query/download_query/cart_add for acting on results. It also clarifies that search needs no login while downstream actions do, so an agent knows when this tool is the right entry point.

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

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/geovicco-dev/bhoonidhi-mcp'

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