Skip to main content
Glama

Get satellite data

get_geo_data
Read-only

Get satellite-derived indicators aggregated over a country, one state/province, or a bounding box. Use for fires, emissions-based activity, rainfall, vegetation, temperature, and soil-moisture questions.

For a sub-national area, call one state/province at a time. Informal regions such as "north India" or "the Midwest" have no boundary, so cover them with one call per state or a bounding box; using the whole country answers a different question. Grid cells and fire detections are activity snapshots, never fire perimeters. For ndvi_s2 and *_tropomi grids, drop or flag cells with low valid_obs_share. Results include units, source attribution, and caveats; cite the attribution. External-provider calls can take about 30 seconds, and rainfall or grid calls can take longer.

Input Schema

NameRequiredDescriptionDefault
regionYesRegion as an ISO3 code or country name ("IND" or "India"); "Country/State" or "ISO3/State" ("India/Punjab" or "CHN/Guangdong") for a state/province; or "bbox:west,south,east,north" in degrees. State/province boundaries are available for IND, CHN, IDN, VNM, THA, MYS, PHL, PAK, BGD, LKA, MMR, KHM, NPL, KOR, JPN, TWN, and USA.
datasetYesSatellite dataset. One of: - "fires_viirs": active fire detections and fire radiative power (NASA FIRMS, 2012->, one day behind). Covers crop-residue burning, forest fires, and flaring. - "no2_tropomi": tropospheric NO2 column (Sentinel-5P, 2018->, ~3 days), an industrial/traffic activity proxy. Check valid_obs_share; cloudy intervals below 0.2 are weakly supported. - "so2_tropomi": SO2 column (Sentinel-5P, 2018->, ~3 days) for coal power, smelting, refining, and volcanoes. Noisy away from strong sources; track trends rather than absolute background levels. - "co_tropomi": CO column (Sentinel-5P, 2018->, ~3 days) for biomass/crop burning and industrial combustion. CO drifts across borders and is seasonal, so compare the same season across years. - "aerosol_index_tropomi": UV aerosol index (Sentinel-5P, 2018->, ~3 days) for smoke, dust, and haze. It is dimensionless; sustained values above ~1 indicate heavy smoke or dust, and it works over clouds. - "ndvi_s2": cloud-masked vegetation NDVI (Sentinel-2, 2017->, ~2-5 days), a crop-condition signal. Check valid_obs_share and compare the same season across years. - "precip_chirps": gauge-calibrated rainfall (CHIRPS, 1981->, ~2 days, 50S-50N) for monsoon, drought, and flood risk. - "precip_imerg": rainfall totals (NASA IMERG V07 Late, 2000->, ~1-2 days, global at 0.1 degree). Use where CHIRPS has no coverage; daily and monthly values are rainfall totals. - "temperature_power": mean/max/min 2m air temperature (NASA POWER, 1981->, ~3 days) for heatwaves and energy demand. - "soil_moisture_power": root-zone soil wetness from 0 to 1 (NASA POWER, 1981->, ~3 days) for agricultural drought. - "wind_power": 10m wind speed, daily maximum, eastward and northward components, the direction the wind blows from, and a 0-1 steadiness score (NASA POWER, 1981->, ~3 days). Use it to separate weather from emission changes in air-pollution data and to trace where smoke comes from. - "humidity_power": 2m relative humidity in % (NASA POWER, 1981->, ~3 days), a weather control for haze and fine particles. NASA POWER serves MERRA-2 up to a cut-off date (2026-08-31 at the time of writing) and the GEOS-IT system after it. The two models sit at different levels, so a one-day step across that date in a POWER dataset is a model change, not weather.
end_dateYesInclusive end date in ISO YYYY-MM-DD format.
resolutionNoOptional fires_viirs grid-cell size in degrees when aggregation="grid"; one of 0.005, 0.01, 0.02, 0.05, 0.1, 0.2, 0.5, 1, 2, or 5. Omit it to choose a size automatically from the region. Values finer than 0.1 read individual detections and return the 500 busiest cells. Not accepted by other datasets or aggregation modes.
start_dateYesInclusive start date in ISO YYYY-MM-DD format.
aggregationNoAggregation mode. "monthly" (default) or "daily" returns a time series. Most datasets allow at most 50 intervals per call (~4 years monthly or ~7 weeks daily); fires_viirs allows 200 (~16 years monthly or ~7 months daily). fires_viirs, ndvi_s2, and *_tropomi also accept "grid": one spatial row per lat/lon cell over the whole window, at most 500 rows, with a 92-day maximum window (366 days for fires). fires_viirs also accepts "seasons", which repeats the requested calendar window in every year since 2012 and returns one row per year, and "points", which returns exact detections only when the window contains at most 500; otherwise use grid or narrow the window.monthly
include_flaresNofires_viirs only. False by default, excluding gas flares, other permanent industrial heat sources, volcanoes, and offshore detections so only vegetation fires are counted. Set true over a gas field or to count every detection NASA publishes.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / dataset / description
      Previous value: -"Satellite dataset. One of:\n- \"fires_viirs\": active fire detections and fire radiative power (NASA FIRMS, 2012->, one day behind). Covers crop-residue burning, forest fires, and flaring.\n- \"no2_tropomi\": tropospheric NO2 column (Sentinel-5P, 2018->, ~3 days), an industrial/traffic activity proxy. Check valid_obs_share; cloudy intervals below 0.2 are weakly supported.\n- \"so2_tropomi\": SO2 column (Sentinel-5P, 2018->, ~3 days) for coal power, smelting, refining, and volcanoes. Noisy away from strong sources; track trends rather than absolute background levels.\n- \"co_tropomi\": CO column (Sentinel-5P, 2018->, ~3 days) for biomass/crop burning and industrial combustion. CO drifts across borders and is seasonal, so compare the same season across years.\n- \"aerosol_index_tropomi\": UV aerosol index (Sentinel-5P, 2018->, ~3 days) for smoke, dust, and haze. It is dimensionless; sustained values above ~1 indicate heavy smoke or dust, and it works over clouds.\n- \"ndvi_s2\": cloud-masked vegetation NDVI (Sentinel-2, 2017->, ~2-5 days), a crop-condition signal. Check valid_obs_share and compare the same season across years.\n- \"precip_chirps\": gauge-calibrated rainfall (CHIRPS, 1981->, ~2 days, 50S-50N) for monsoon, drought, and flood risk.\n- \"precip_imerg\": rainfall totals (NASA IMERG V07 Late, 2000->, ~1-2 days, global at 0.1 degree). Use where CHIRPS has no coverage; daily and monthly values are rainfall totals.\n- \"temperature_power\": mean/max/min 2m air temperature (NASA POWER, 1981->, ~3 days) for heatwaves and energy demand.\n- \"soil_moisture_power\": root-zone soil wetness from 0 to 1 (NASA POWER, 1981->, ~3 days) for agricultural drought.\n- \"wind_power\": 10m wind speed, daily maximum, eastward and northward components, the direction the wind blows from, and a 0-1 steadiness score (NASA POWER, 1981->, ~3 days). Use it to separate weather from emission changes in air-pollution data and to trace where smoke comes from.\n- \"humidity_power\": 2m relative humidity in % (NASA POWER, 1981->, ~3 days), a weather control for haze and fine particles."New value: +"Satellite dataset. One of:\n- \"fires_viirs\": active fire detections and fire radiative power (NASA FIRMS, 2012->, one day behind). Covers crop-residue burning, forest fires, and flaring.\n- \"no2_tropomi\": tropospheric NO2 column (Sentinel-5P, 2018->, ~3 days), an industrial/traffic activity proxy. Check valid_obs_share; cloudy intervals below 0.2 are weakly supported.\n- \"so2_tropomi\": SO2 column (Sentinel-5P, 2018->, ~3 days) for coal power, smelting, refining, and volcanoes. Noisy away from strong sources; track trends rather than absolute background levels.\n- \"co_tropomi\": CO column (Sentinel-5P, 2018->, ~3 days) for biomass/crop burning and industrial combustion. CO drifts across borders and is seasonal, so compare the same season across years.\n- \"aerosol_index_tropomi\": UV aerosol index (Sentinel-5P, 2018->, ~3 days) for smoke, dust, and haze. It is dimensionless; sustained values above ~1 indicate heavy smoke or dust, and it works over clouds.\n- \"ndvi_s2\": cloud-masked vegetation NDVI (Sentinel-2, 2017->, ~2-5 days), a crop-condition signal. Check valid_obs_share and compare the same season across years.\n- \"precip_chirps\": gauge-calibrated rainfall (CHIRPS, 1981->, ~2 days, 50S-50N) for monsoon, drought, and flood risk.\n- \"precip_imerg\": rainfall totals (NASA IMERG V07 Late, 2000->, ~1-2 days, global at 0.1 degree). Use where CHIRPS has no coverage; daily and monthly values are rainfall totals.\n- \"temperature_power\": mean/max/min 2m air temperature (NASA POWER, 1981->, ~3 days) for heatwaves and energy demand.\n- \"soil_moisture_power\": root-zone soil wetness from 0 to 1 (NASA POWER, 1981->, ~3 days) for agricultural drought.\n- \"wind_power\": 10m wind speed, daily maximum, eastward and northward components, the direction the wind blows from, and a 0-1 steadiness score (NASA POWER, 1981->, ~3 days). Use it to separate weather from emission changes in air-pollution data and to trace where smoke comes from.\n- \"humidity_power\": 2m relative humidity in % (NASA POWER, 1981->, ~3 days), a weather control for haze and fine particles.\nNASA POWER serves MERRA-2 up to a cut-off date (2026-08-31 at the time of writing) and the GEOS-IT system after it. The two models sit at different levels, so a one-day step across that date in a POWER dataset is a model change, not weather."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only, open-world, idempotent=false, non-destructive, but the description adds substantial behavior beyond them: ~30s latency for external providers (longer for rainfall/grid), the fact that grids and detections are activity snapshots rather than fire perimeters, and that results carry units, source attribution, and caveats that must be cited. This is exactly the extra operational context the annotations cannot express.

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?

Three tight paragraphs, front-loaded with the core capability before the operational caveats. It is slightly dense and packs several distinct rules (region enumeration, grid caveats, attribution, latency) into one block, but no sentence is filler.

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?

For a 7-parameter tool with a full input schema and an output schema, the description supplies everything else an agent needs: scope selection, spatial granularity traps, data-quality handling, and latency expectations. Return-value detail is correctly left to the output schema.

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 description coverage is 100%, so the baseline is 3; the description lifts it by adding usage-level semantics for region (sub-national boundaries must be enumerated, informal regions have none) and for grid outputs (ndvi_s2 and *_tropomi valid_obs_share handling). It doesn't restate per-dataset parameter rules that the schema already covers in depth, which is appropriate.

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 first sentence names a specific verb and resource (retrieval of satellite-derived indicators) and states the three supported spatial scopes (country, state/province, bounding box). It enumerates the subject areas (fires, emissions, rainfall, vegetation, temperature, soil moisture), which cleanly separates it from siblings like get_market_data or search_news.

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?

Explicit routing guidance: call one state/province at a time, cover informal regions ('north India') with per-state calls or a bbox, and a stated reason why the country-level call answers a different question. It also flags when to drop/flag low valid_obs_share cells and cites the alternative caveats, giving the agent concrete when-to-use and when-not-to-use rules.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources