Skip to main content
Glama

factiq

Get satellite data

get_geo_data

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

TableJSON 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.
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

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations cover safety profile only (readOnlyHint=false, openWorldHint=true, destructedHint=false), leaving the description to carry operational behavior — and it does: ~30s latency for external providers, longer for rainfall/grid calls, returned units/attribution/caveats, and the requirement to cite attribution. It also discloses an interpretation hazard ('grid cells and fire detections are activity snapshots, never fire perimeters') and a data-quality rule for low valid_obs_share.

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 purpose, then the sub-national rule, then data caveats and latency. Sentence-level density is high and little is filler, though the caveat block could be trimmed slightly without losing signal.

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, open-world data retrieval tool with an output schema already documenting return shape, the description supplies everything else an agent needs: scope granularity, latency expectations, attribution obligations, and interpretation caveats. Nothing material is left for the agent to guess.

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, and the description adds genuine meaning on top: the one-state-per-call constraint for the region parameter, the informal-region workaround, and the pointer to filter low valid_obs_share for ndvi_s2 and *_tropomi grids. It does not restate dataset/resolution syntax, which the schema already handles well.

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?

The description opens with a specific verb+resource ('Get satellite-derived indicators') and pins down the aggregation scope (country, state/province, or bounding box), which is more precise than the title 'Get satellite data'. It does not explicitly name competing siblings (search_datasets, get_series, run_sql), though the domain is narrow enough that an agent can separate it by subject matter alone.

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?

It names the question types the tool answers ('fires, emissions-based activity, rainfall, vegetation, temperature, and soil-moisture questions') and gives explicit operational rules: one state/province per call for sub-national areas, bounding boxes for informal regions, and the warning that 'using the whole country answers a different question.' The exclusion of borderless informal regions is exactly the kind of when-not guidance that prevents misuse.

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