Skip to main content
Glama

earthquake-mcp-server

Search Earthquakes

earthquake_search
Read-onlyIdempotent

Search earthquakes by time range, magnitude, depth, location radius, PAGER alert level, or felt reports. Supports USGS (global, richer metadata: PAGER, DYFI, ShakeMap) and EMSC, an independent global catalog operated by the European-Mediterranean Seismological Centre. For location-based queries, provide latitude, longitude, and radius_km together. A rectangular study area is expressed with min_latitude, max_latitude, min_longitude, and max_longitude — each independently optional, so a single edge is a valid constraint. Combining the box with the lat/lon/radius circle intersects the two, returning only events inside both. Both catalogs include non-tectonic records (quarry blasts, explosions) — every event carries its event_type, and event_type="earthquake" filters the rest out on USGS. USGS-specific filters (alert_level, event_type, min_felt, min_significance) are not sent when source=emsc — the response names them in ignoredFilters. Use earthquake_count first to gauge result size before requesting large result sets. A single call returns at most 20,000 events; larger result sets are retrieved by paging with offset, which is passed straight through to the upstream FDSN API. When a result is capped, nextOffset carries the offset for the following page and totalCount the full match count — or countUnavailable reports that the count lookup failed and the total is unknown.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum events to return per call. Default 100. Large limits (>1000) may result in slow responses. Max 20000. Combine with offset to retrieve match sets larger than one call can return.
offsetNoIndex of the first event to return, counting from 1 — offset=1 is the first match (both upstream APIs reject 0). Omit for the first page, then pass the nextOffset value from a capped result to fetch the next one. Ordering is set by order_by, so keep order_by, limit, and every filter identical across pages.
sourceNoData source. Both catalogs are global. "usgs" covers global events with PAGER, DYFI, and ShakeMap metadata. "emsc" is an independent global catalog operated by the European-Mediterranean Seismological Centre — use it to cross-check any event, anywhere, against a separate network. It publishes no PAGER, DYFI, or ShakeMap metadata and no per-event detail endpoint; its station coverage is densest around Europe and the Mediterranean.usgs
end_timeNoEnd of time range as ISO 8601, in the same forms start_time accepts. Defaults to current time if omitted.
latitudeNoLatitude for radius search. Requires longitude and radius_km.
min_feltNoMinimum number of DYFI (Did You Feel It?) reports. Use to find events with confirmed public impact. Only available from USGS.
order_byNoSort order. "time" returns newest first; "magnitude" returns largest first.time
longitudeNoLongitude for radius search. Requires latitude and radius_km.
radius_kmNoSearch radius in kilometers from the lat/lon point. 100 km covers a metro region; 500 km covers a large country. Max 20001.6, the ceiling USGS enforces. Converted to degrees for EMSC (1° ≈ 111.2 km).
event_typeNoFilter by upstream event classification, e.g. "earthquake" to exclude quarry blasts and explosions, or "quarry blast" to see only those. Matched verbatim against the USGS catalog, which accepts any string and returns zero matches for an unrecognized one. Only available from USGS.
start_timeNoStart of time range as ISO 8601 (e.g. "2026-01-01" or "2026-05-23T00:00:00"). A bare year expands to January 1st and an unpadded month or day is zero-padded, so both sources honor the same window. Defaults to 30 days before end_time (or before the current time) if omitted — applied server-side so USGS and EMSC honor the same window.
alert_levelNoMinimum PAGER alert level. PAGER estimates economic loss and casualties. "green" = minimal impact; "red" = extreme. Only available from USGS.
max_depth_kmNoMaximum depth in kilometers. Bounded to the documented -100 to 1000 km catalog envelope.
max_latitudeNoNorthern edge of a bounding-box search, in degrees.
min_depth_kmNoMinimum depth in kilometers. Bounded to the documented -100 to 1000 km catalog envelope. Shallow quakes (0–70 km) typically cause more surface damage than deep quakes (>300 km).
min_latitudeNoSouthern edge of a bounding-box search, in degrees. Independent of the other three box parameters — supply any of them. Must not exceed max_latitude when both are given.
max_longitudeNoEastern edge of a bounding-box search, in degrees.
max_magnitudeNoMaximum magnitude.
min_longitudeNoWestern edge of a bounding-box search, in degrees. Range extends beyond ±180 so a box can cross the antimeridian (e.g. min_longitude=170, max_longitude=190) — always keep min_longitude at or below max_longitude rather than inverting the pair.
min_magnitudeNoMinimum magnitude (Richter or equivalent). M2.5+ is felt by some people; M5+ can cause damage; M7+ is major.
min_significanceNoMinimum USGS significance score (0–2000+). Combines magnitude, felt reports, and PAGER estimates. Significant events typically score 600+. Only available from USGS.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoNumber of events returned.
errorNoPresent when the call failed. Absent on success.
eventsNoMatching earthquake events.
noticeNoRecovery guidance when results are empty or capped — how to broaden filters or get the full count. Absent when the result set is non-empty and within the limit.
sourceNoData source used.
queryEchoNoEcho of the effective parameters sent to the upstream API, including server-resolved defaults. Use to diagnose unexpected or empty results — a filter absent here was not sent upstream.
truncatedNoTrue when results were capped by the limit parameter. totalCount carries the full match count when available, and nextOffset the input for the following page. With countUnavailable set the total is unknown, so this flag means the page was filled, not that more events are confirmed to remain.
nextOffsetNoValue to pass as the offset input to retrieve the next page, with every other input unchanged. Present only when more events remain; absent means this was the last page.
totalCountNoTotal events matching the query before the limit was applied. Fetched via a follow-up count query when results are truncated at the limit. Absent when results were not capped, and when that follow-up query failed — countUnavailable separates the two.
ignoredFiltersNoUSGS-only filters supplied in the input but not sent upstream because source=emsc does not support them. The result set is NOT constrained by these — re-run with source=usgs to apply them. Absent when every supplied filter was applied.
countUnavailableNoTrue when the follow-up total-count query failed, so the total is unknown for this call rather than never requested. The returned events are complete and unaffected; only totalCount is missing. Retry earthquake_count with the same filters to recover the total. Absent whenever the count succeeded or was never needed.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations (readOnlyHint, openWorldHint, idempotentHint) declare a safe, read-only op, and the description does not contradict them. It adds substantial behavior beyond annotations: the 20,000-event cap and offset paging, nextOffset/totalCount/countUnavailable reporting, the ignoredFilters behavior for USGS-specific params when source=emsc, inclusion of non-tectonic records, and the box+circle intersection semantics. This richly exceeds the annotation baseline for a read-only search tool.

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 description is long (roughly 280 words) but dense, and every sentence carries distinct information: scope, source comparison, location semantics, non-tectonic filtering, ignoredFilters, size-guard guidance, and paging. For a 21-parameter, dual-source tool with complex location and paging behavior, this length is justified rather than padded. It is front-loaded with purpose before procedural detail, though it is not as terse as it could be.

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?

Given the tool's complexity (21 parameters, two sources, antimeridian crossing, box+circle intersection, ignoredFilters, paging), the description is remarkably complete. Non-obvious semantics are all covered: source-specific filter behavior, count-unavailable edge case, and 'single edge is a valid constraint.' Since an output schema exists, the description need not explain return shape, and the schema handles per-parameter format details at 100% coverage. Nothing an agent needs to call this correctly is missing.

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 coverage is 100%, so the baseline is 3. The description adds genuine value beyond the schema by expressing cross-parameter relationships: lat/long/radius_km must be supplied together, the four box edges are independently optional, and combining box with circle 'intersects the two, returning only events inside both.' These relational constraints are not fully legible from the individual property descriptions, elevating the contribution to a 4.

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 statement: 'Search earthquakes by time range, magnitude, depth, location radius, PAGER alert level, or felt reports.' It names the two data sources (USGS, EMSC) and explicitly routes to a sibling: 'Use earthquake_count first to gauge result size,' making it distinguishable from earthquake_count, earthquake_get_event, and earthquake_get_feed without inspecting their schemas.

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?

Provides explicit when-to-use guidance for the most likely confusion: 'Use earthquake_count first to gauge result size before requesting large result sets' and explains when to prefer EMSC ('use it to cross-check any event, anywhere, against a separate network'). It also details paging usage with nextOffset. It does not, however, explicitly contrast against earthquake_get_event/earthquake_get_feed, so a small routing gap remains.

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.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool serves a clear, distinct purpose: count for statistical queries, search for filtered record retrieval, feed for pre-computed real-time data, and get_event for per-event detail. Overlap between count and search is explicitly addressed with guidance on when to use each. No two tools appear interchangeable.

Naming Consistency5/5

All tools follow the consistent pattern of earthquake_ + verb (count, get_event, get_feed, search), making the action and resource unambiguous. The naming is uniform across all four tools, with no mixed conventions or vague verbs.

Tool Count5/5

With 4 tools, the surface is tightly scoped and each tool covers a necessary operation for the domain. This is well within the ideal 3-15 range and neither feels thin nor overloaded for an earthquake data server.

Completeness5/5

The tool set covers the core workflows: searching with rich filters, counting for statistics, retrieving detailed event info, and accessing real-time feeds. No significant gaps are apparent—the server supports both USGS and EMSC sources, and the read-only nature is appropriate for the domain.