Skip to main content
Glama
Sign In

Nasa Eonet

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Nasa Eonet Events

nasa_eonet_events
Read-onlyIdempotent

Natural hazard events tracked by NASA EONET (the Earth Observatory Natural Event Tracker): wildfires, severe storms, volcanoes, floods, icebergs, landslides, dust and haze. Filter by open or closed status, lookback days, category id, bounding box, reporting source, and magnitude range. Returns each event id, title, category, date-stamped geometry (point or polygon), and links to the reporting agency, answering where wildfires, storms, or eruptions are active now and where they occurred recently.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "days": 30,
      "limit": 50,
      "status": "open"
    },
    "name": "nasa_eonet_events"
  }
}

Input Schema

NameRequiredDescriptionDefault
bboxNoBounding box: "min_lon,max_lat,max_lon,min_lat" (note non-standard order)
daysNoLookback window in days (default 30, default 30 for closed)
limitNoMax results
sourceNoComma-sep source ids (see list_sources)
statusNoopen (default) | closed | all
categoryNoComma-sep category ids (e.g. "wildfires,severeStorms")
magnitude_idNoFilter by magnitude id (e.g. "ac" for acres)
magnitude_maxNoMaximum magnitude
magnitude_minNoMinimum magnitude

Output Schema

NameRequiredDescriptionDefault
linkNo
titleNo
eventsNoList of natural events
descriptionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered. The description adds genuinely useful behavioral detail beyond the annotations: that status defaults to open (so results are filtered by default) and that geometry is date-stamped point-or-polygon, which affects how results must be interpreted. It stops short of discussing pagination or result caps relative to the limit parameter.

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 sentences are ordered as what -> filters -> returns, with no filler and the hazard taxonomy front-loaded. The return-value sentence is somewhat redundant given an output schema exists, which keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, zero-required read tool with full annotation coverage and an output schema, the definition covers identity, filtering surface, and result shape adequately. The only omission is guidance on result volume and how limit interacts with days, which is a minor gap rather than a blocker.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 restates the filter dimensions (status, lookback days, category, bbox, source, magnitude range) in prose but adds no syntax or format detail beyond what the schema already documents, including the non-standard bbox ordering which lives only in the schema.

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 gives a specific resource (NASA EONET natural hazard events) and enumerates the hazard types plus the filterable dimensions, so the agent knows exactly what set is being queried. It does not name or contrast the sibling tools (nasa_eonet_geojson, nasa_eonet_get_event), so an agent must infer that this returns the list in regular JSON rather than GeoJSON or a single event.

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

Usage Guidelines3/5

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

The closing phrase 'answering where wildfires, storms, or eruptions are active now and where they occurred recently' implies the use case, but there is no explicit when-not guidance and no routing to nasa_eonet_geojson or nasa_eonet_get_event when those would be more appropriate. Usage is inferable rather than stated.

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

All Nasa Eonet toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources