MapMap

events_in_area

Earthquakes, volcano alerts and satellite fire detections in a bounding box, for display. Pass bbox [west, south, east, north] (WGS84), optional types (quake, volcano, fire; default all), min_magnitude (quakes, default 2.5) and limit (1 to 500, default 100). Earthquakes are USGS, magnitude 2.5 and above, past 24 hours, as reported (magnitudes and locations may be revised). Volcano alerts are USGS-monitored volcanoes ONLY: an absent alert says nothing about volcanoes elsewhere. Fire cells are NASA FIRMS VIIRS detections thinned to 0.5 degree cells: satellite-detected heat, NOT confirmed fires. Each feed carries status (ok, stale, unknown): pass a stale or unknown status on, never present old data as current. This is reported data for display, not a warning service and not safety-critical; keep that qualifier when you pass it on. Requires the MapMap gateway. Display the returned attribution, and for fire data the FIRMS acknowledgment and disclaimer.

Input Schema

Name	Required	Description
`bbox`	Yes	Bounding box `[west, south, east, north]`, WGS84 degrees. West must be less than east and south less than north; a box crossing the antimeridian is not supported (query two boxes).
`limit`	No	Most events to return, 1 to 500 (default 100). Newest quakes first, then volcano alerts, then the busiest fire cells.
`types`	No	Which feeds to include: any of `quake`, `volcano`, `fire`. Default: all three.
`min_magnitude`	No	Smallest earthquake magnitude, 2.5 to 9.0 (default 2.5). Quakes only.

Output Schema

Name	Required	Description
`count`	Yes	Events returned.
`feeds`	Yes	Freshness of each requested feed, keyed `quake`, `volcano`, `fire`.
`label`	Yes	Reported events for display; not a warning service. Pass it on.
`events`	Yes	The events: newest quakes, then volcano alerts, then fire cells.
`summary`	Yes	One sentence built from the counts. Pass it on with its qualifier.
`coverage`	Yes	What each feed does and does not cover. Pass it on.
`truncated`	Yes	True when the limit cut the list short.
`disclaimer`	Yes	NASA FIRMS "as is" disclaimer. Display it with fire data.
`attribution`	Yes	Source credits, keyed by feed. Display them.
`endorsement`	Yes	No endorsement by or affiliation with USGS, NOAA or NASA is implied.
`acknowledgment`	Yes	NASA FIRMS acknowledgment. Display it with fire data.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 17, 2026

TDQS

A4.4/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so thoroughly: gateway dependency, data provenance (USGS, NASA FIRMS), freshness windows, the volcano-only monitoring limitation, fire cells being unconfirmed heat rather than confirmed fires, and revision warnings. These are exactly the behavioral traits an agent needs and which annotations would otherwise cover.

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?

Purpose and bbox format are front-loaded and the dense caveats stay on-topic; nothing reads as filler. It is long and heavily packed, but each clause (attribution, acknowledgment, disclaimer requirements) earns its place.

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?

With an output schema present, return-value detail is unnecessary, and the description instead supplies the non-schema essentials: gateway requirement, caveats about data reliability, status propagation, and required attribution text. Nothing an agent needs to call or responsibly relay this tool is missing.

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 schema already documents bbox format, defaults, ranges and ordering; the description mostly restates these (bbox WGS84, defaults, quakes-only min_magnitude). It adds little semantics beyond the schema, so the baseline of 3 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?

Names a specific resource (earthquake/volcano/fire events) with an explicit spatial scope (bounding box) and a stated intent (for display). An agent can distinguish it from geo_bbox or space_weather_now without opening any schema.

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

Usage Guidelines4/5

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

Gives clear usage context and exclusions: 'for display, not a warning service and not safety-critical', and instructs that stale/unknown status must be passed on rather than presented as current. It does not name an alternative sibling to use instead, so it falls short of an explicit routing rule.

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

All MapMap tools Inspect

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

Need Help?