Skip to main content
Glama

query_nightlights

Read-onlyIdempotent

Query NASA Black Marble night-lights (VIIRS VNP46A2, ~500 m): moonlight/atmosphere-corrected nighttime radiance sampled nightly at every FIRMS-watched facility, plus significance events judged against each facility's OWN clear-night baseline. Two modes. mode="events" (default) reads SITE-LEVEL significance events — went_dark_lights (a habitually-lit facility dark across several consecutive CLEAR nights: the outage signal), surge (materially brighter than its own norm), first_light (a reliably-dark facility lights up). Use it for "which power stations went dark last week", "unusual lighting activity in Kuwait". mode="radiance" reads the per-facility nightly radiance rollup — use it for baseline questions ("how bright is Bandar Abbas at night", "clear-night trend at Az Zour"). CRITICAL INTERPRETATION RULES — RADIANCE IS NOT POWER STATE. A dark pixel is not a confirmed outage: cloud, snow, moon geometry and the ~500 m footprint all hide light, so went_dark_lights requires SUSTAINED absence across multiple confidently-CLEAR nights and is still an inference, never a verdict. Judgements use confident_clear observations ONLY (cloud scatters city light back at the sensor — cloudy readings average ~100x brighter and would fake both surges and collapses). ABSENCE OF A ROW IS ABSENCE OF A LOOK, never darkness. Counts are per PHYSICAL SITE, not per registry row (one plant = many generating-unit rows at identical coordinates). LATENCY: NASA publishes VNP46A2 in stages, typically ~1-2 WEEKS behind — every response carries a coverage block with newest_night and lag_days; answers describe that week, NOT last night, and you must say so. Thermal (FIRMS) and night-lights measure DIFFERENT PHYSICS — infrared heat vs visible emitted light — but they are NOT independent sensors: both are NASA VIIRS-family, and the same clouds and overpass timing blind both. Agreement between them (e.g. a FIRMS went_dark and a went_dark_lights at the same facility) is stronger evidence than either alone, never independent confirmation. Check both before characterising an outage.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoLook-back window in days ENDING AT THE NEWEST DATA NIGHT (not today — see coverage.lag_days). Default 14, max 60.
modeNo"events" (default, site-level significance) | "radiance" (per-facility nightly rollup).
limitNoDefault 50, max 500.
countryNoCountry-name substring (e.g. "Kuwait", "Saudi"). NOTE: attribution is dense for power plants but sparse for refineries — prefer facility_name for refineries.
event_typeNoevents mode: went_dark_lights | surge | first_light. Filter optional.
facility_nameNoFacility/site-name substring (e.g. "Az Zour", "Bandar Abbas"). Filter optional.
facility_typeNoradiance mode: refinery | power_plant. Filter optional.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, and the description substantially enriches these with operational caveats: 'RADIANCE IS NOT POWER STATE', 'ABSENCE OF A ROW IS ABSENCE OF A LOOK, never darkness', and cloud-induced ~100x brightness artifacts. It also discloses latency (~1-2 weeks) and the coverage block, which is exactly the kind of behavioral context annotations cannot express. No contradiction with annotations.

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 text is long, but it is densely packed with no filler and is organized with clear section boundaries ('Two modes', 'CRITICAL INTERPRETATION RULES'). It front-loads the core purpose before the caveats, which helps agents absorb the critical interpretation rules in context. It loses one point only because a more compact presentation of the very detailed caveats might be slightly easier to parse, though the length is largely justified by 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?

For a tool with no output schema and rich domain-specific semantics, the description is remarkably complete: it covers both output modes, the coverage block, expected response content, interpretation pitfalls, and relationships to thermal data. It also supplies the connection to sibling tools and sufficient guidance on filters for correct use. An agent has everything it needs to invoke the tool correctly and interpret results appropriately.

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?

Although schema coverage is 100%, the description adds significant semantic value: it explains what event_type values mean ('went_dark_lights', 'surge', 'first_light'), clarifies that counts are per physical site rather than registry row, and gives concrete examples for facility_name and country. It also adds interpretative constraints like 'days' ending at the newest data night, which prevents misuses the bare schema would not. This goes well beyond the parameter descriptions.

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, resource, and resolution: 'Query NASA Black Marble night-lights (VIIRS VNP46A2, ~500 m)'. It clearly distinguishes the two operating modes, 'events' and 'radiance', with explicit example questions, which differentiates it from sibling tools like query_thermal_anomalies. An agent can confidently determine what this tool does and what it does not do.

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 explicit when-to-use guidance for each mode: 'Use it for "which power stations went dark last week"' vs 'use it for baseline questions'. It also explains when thermal and night-lights should be used together ('Check both before characterising an outage') and why they are not independent. This is strong routing guidance relative to both modes and sibling tools.

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