earthquake-mcp-server
Server Details
Search USGS and EMSC seismic data — real-time feeds, event queries, and earthquake counts.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/earthquake-mcp-server
- GitHub Stars
- 1
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.8/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: count aggregates, get_event fetches detail, get_feed retrieves real-time feeds, and search performs historical/filtered queries. No overlap in functionality.
All tool names follow a consistent 'earthquake_verb_noun' pattern (e.g., earthquake_count, earthquake_get_event). The naming is predictable and intuitive.
Four tools is an appropriate number for earthquake data retrieval. The set covers the essential operations without being excessive or insufficient.
The tools cover main use cases: search, count, feed, and event details. Minor gap: no direct tool for bulk listing by region, but search with filters compensates. Slightly missing a get_all_events, but overall very good.
Available Tools
4 toolsearthquake_countCount EarthquakesARead-onlyIdempotentInspect
Count earthquakes matching filters without fetching full records. Use for statistical queries ("how many M5+ earthquakes in 2025?") or to gauge result size before calling earthquake_search. Omitting start_time counts only the last 30 days, so pass an explicit range for any period-specific question; queryEcho reports the window and filters the count actually covers. When exceeds_limit is true, the count exceeds 20,000 and a full search would be truncated — narrow filters before fetching. USGS returns the max_allowed cap (20,000); EMSC count endpoint does not return this field (max_allowed will be null). Both catalogs include non-tectonic records, so a radius over a mining region counts quarry blasts alongside earthquakes — pass event_type="earthquake" on USGS to exclude them. USGS-specific filters (alert_level, event_type, min_felt, min_significance) are not sent when source=emsc — the response names them in ignoredFilters.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Data 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 a count from a separate network. It has no PAGER, DYFI, or ShakeMap metadata; its station coverage is densest around Europe and the Mediterranean, so counts of small events differ most by region. | usgs |
| end_time | No | End of time range as ISO 8601. Defaults to current time if omitted. | |
| latitude | No | Latitude for radius search. Requires longitude and radius_km. | |
| min_felt | No | Minimum number of DYFI (Did You Feel It?) reports. Use to count events with confirmed public impact. Only available from USGS. | |
| longitude | No | Longitude for radius search. Requires latitude and radius_km. | |
| radius_km | No | Search radius in kilometers from the lat/lon point. Converted to degrees for EMSC (1° ≈ 111.2 km). | |
| event_type | No | Filter by upstream event classification, e.g. "earthquake" to exclude quarry blasts and explosions from the count, or "quarry blast" to count only those. Matched verbatim against the USGS catalog, which accepts any string and returns a count of zero for an unrecognized one. Only available from USGS. | |
| start_time | No | Start of time range as ISO 8601 (e.g. "2026-01-01" or "2026-05-23T00:00:00"). 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_level | No | Minimum PAGER alert level. PAGER estimates economic loss and casualties. "green" = minimal impact; "red" = extreme. Only available from USGS. | |
| max_depth_km | No | Maximum depth in kilometers. | |
| min_depth_km | No | Minimum depth in kilometers. Shallow quakes (0–70 km) typically cause more surface damage than deep quakes (>300 km). | |
| max_magnitude | No | Maximum magnitude. | |
| min_magnitude | No | Minimum magnitude (Richter or equivalent). M2.5+ is felt by some people; M5+ can cause damage; M7+ is major. | |
| min_significance | No | Minimum USGS significance score (0–2000+). Combines magnitude, felt reports, and PAGER estimates. Significant events typically score 600+. Only available from USGS. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of events matching the query. |
| source | Yes | Data source used. |
| queryEcho | No | Echo of the effective parameters the count covers, including server-resolved defaults. Read start_time and end_time to know which window the count spans — a filter absent here was not sent upstream. |
| max_allowed | Yes | Maximum events the API would return for a full fetch. 20000 for USGS. Null for EMSC — the EMSC count endpoint does not return this field. |
| exceeds_limit | Yes | True when count exceeds 20000 — a full earthquake_search would be truncated. For EMSC, evaluated against the known 20000 limit since max_allowed is not returned. Narrow filters to retrieve all matching events. |
| ignoredFilters | No | USGS-only filters supplied in the input but not sent upstream because source=emsc does not support them. The count is NOT constrained by these — re-run with source=usgs to apply them. Absent when every supplied filter was applied. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. The description adds behavioral details: exceeds_limit meaning, max_allowed field null for EMSC, and ignored USGS-specific filters when source=emsc. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and usage, then caveats. It is slightly long but every sentence adds value; could be trimmed slightly for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, multiple sources, output schema exists, the description covers all necessary aspects: purpose, usage, source differences, parameter behaviors, limit handling. Complete and thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about start_time default, radius_km conversion, and source-specific filters, but most parameter details are already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Count earthquakes matching filters without fetching full records' and distinguishes from earthquake_search. It uses specific verbs and resources, and mentions statistical queries and result size gauging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: for statistical queries or to gauge result size before calling earthquake_search. Warns about exceeds_limit and narrowing filters. Explains source-specific behaviors (USGS vs EMSC).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
earthquake_get_eventGet Earthquake Event DetailARead-onlyIdempotentInspect
Fetch detail for a specific earthquake by USGS event ID. Returns the same normalized event a search result carries, plus a projection of the analysis products only the single-event response holds: PAGER impact alert and report link, ShakeMap peak intensity and ground motion, DYFI felt-report totals, the moment-tensor focal mechanism, landslide and liquefaction alerts, origin quality (azimuthal gap, station count, location uncertainty), and finite-fault rupture dimensions. Products are omitted when USGS produced none — a small automatic event typically has no detail at all, while a large reviewed one has most of it. Event IDs appear in the "id" field of earthquake_get_feed and earthquake_search results. This tool is USGS-only — EMSC events have no per-event detail endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | USGS event ID, e.g. "hv74966427" or "us6000sznj". Found in the "id" field of earthquake_get_feed and earthquake_search results. |
Output Schema
| Name | Required | Description |
|---|---|---|
| event | Yes | Full earthquake event detail. |
| detail | No | Analysis products USGS attached to this event. Absent when the event carries none — that means no product was produced, not that impact was zero. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. Description adds specific behavioral details: returns felt reports (DYFI), ShakeMap maximum intensity (MMI), PAGER alert level, tsunami flag, and magnitude type. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and return fields; second clarifies source and limitation. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, simple output with existing output schema), the description is complete. It covers what the tool returns, how to get the event ID, and a notable limitation (USGS-only).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter event_id. Description provides examples and cross-references to where the ID comes from, adding significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Fetch' and resource 'earthquake detail by USGS event ID'. It differentiates from siblings by specifying that event IDs come from earthquake_get_feed and earthquake_search, and that it is USGS-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly states when not to use the tool (EMSC events have no endpoint). It also indicates that event IDs are sourced from other tools, providing clear context. Could slightly benefit from more explicit alternative naming, but it's sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
earthquake_get_feedGet USGS Earthquake FeedARead-onlyIdempotentInspect
Fetch a USGS pre-computed real-time earthquake feed by magnitude tier and time window. These feeds are CDN-cached by USGS and faster and more available than the query API — use them for "what's happening now" queries. "all" includes microseisms (M<1); "significant" is a USGS curation based on magnitude, felt reports, and PAGER impact estimates. "hour" returns 0–10 events typically; "month" can exceed 10,000 for the "all" tier, so results are returned a page at a time: count is the page size, totalCount the whole feed, and nextCursor the input for the following page. The cursor is opaque and must be passed back verbatim — unlike earthquake_search, these feeds have no upstream paging parameter and USGS regenerates them about once a minute, so a numeric offset across two calls would skip or repeat events. For historical or filtered queries, use earthquake_search instead.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum events to return in this call. Default 100, max 1000. Applies to the first page; later pages carry the page size inside the cursor, so set it on the first call rather than changing it mid-sequence. | |
| cursor | No | Opaque token for the next page, taken verbatim from a previous call's nextCursor. Omit for the first page. Do not construct, parse, or edit it — it encodes a position in the feed snapshot and is rejected if malformed. | |
| time_window | No | Time window for the feed. "hour" typically returns 0–10 events; "month" can exceed 10,000 for the "all" tier. Prefer "hour" or "day" for real-time status checks. | day |
| magnitude_tier | No | Minimum magnitude threshold for the feed. "all" includes microseisms (M<1). "1.0" is M1.0+. "2.5" is M2.5+. "4.5" is M4.5+. "significant" is a USGS curated selection based on magnitude, felt reports, and PAGER impact estimates — not purely magnitude-based. | 2.5 |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of events returned in this page, not the whole feed. |
| events | Yes | Earthquake events for this page, newest first. |
| notice | No | Recovery guidance when the feed contains no events, or how to continue when a page was capped — narrowing the magnitude tier, widening the time window, paging with the cursor, or using earthquake_search for filtered queries. Absent when a single page covers the whole feed. |
| feed_url | Yes | Source feed URL. |
| truncated | No | True when the feed holds more events than this page returned. nextCursor carries the input for the following page. |
| nextCursor | No | Opaque token to pass back as the cursor input for the next page. Present only when more events remain; absent means this was the last page. |
| totalCount | No | Number of events in the whole feed, across every page. |
| generated_at | Yes | ISO 8601 UTC timestamp when this feed was generated by USGS. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that feeds are CDN-cached, explains behavior of 'all' vs 'significant' tiers, and gives typical event counts per time window. Adds context beyond annotations (readOnlyHint, etc.) without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, each providing value. Front-loaded with main purpose, no redundancy or fluff. Efficiently conveys all necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters, full schema coverage, output schema, and annotations, the description covers usage context, behavior, and alternatives comprehensively. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context like event count expectations for time windows and definition of 'significant'. Slightly above baseline because it enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a USGS pre-computed real-time earthquake feed by magnitude tier and time window. It distinguishes from siblings by mentioning earthquake_search for historical/filtered queries, and the verb 'fetch' is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends use for 'what's happening now' queries, notes faster and more available than query API, and directs to earthquake_search for historical or filtered queries. Provides clear when and when-not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
earthquake_searchSearch EarthquakesARead-onlyIdempotentInspect
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. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum 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. | |
| offset | No | Index 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. | |
| source | No | Data 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_time | No | End of time range as ISO 8601. Defaults to current time if omitted. | |
| latitude | No | Latitude for radius search. Requires longitude and radius_km. | |
| min_felt | No | Minimum number of DYFI (Did You Feel It?) reports. Use to find events with confirmed public impact. Only available from USGS. | |
| order_by | No | Sort order. "time" returns newest first; "magnitude" returns largest first. | time |
| longitude | No | Longitude for radius search. Requires latitude and radius_km. | |
| radius_km | No | Search radius in kilometers from the lat/lon point. 100 km covers a metro region; 500 km covers a large country. Converted to degrees for EMSC (1° ≈ 111.2 km). | |
| event_type | No | Filter 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_time | No | Start of time range as ISO 8601 (e.g. "2026-01-01" or "2026-05-23T00:00:00"). 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_level | No | Minimum PAGER alert level. PAGER estimates economic loss and casualties. "green" = minimal impact; "red" = extreme. Only available from USGS. | |
| max_depth_km | No | Maximum depth in kilometers. | |
| min_depth_km | No | Minimum depth in kilometers. Shallow quakes (0–70 km) typically cause more surface damage than deep quakes (>300 km). | |
| max_magnitude | No | Maximum magnitude. | |
| min_magnitude | No | Minimum magnitude (Richter or equivalent). M2.5+ is felt by some people; M5+ can cause damage; M7+ is major. | |
| min_significance | No | Minimum USGS significance score (0–2000+). Combines magnitude, felt reports, and PAGER estimates. Significant events typically score 600+. Only available from USGS. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of events returned. |
| events | Yes | Matching earthquake events. |
| notice | No | Recovery 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. |
| source | Yes | Data source used. |
| queryEcho | No | Echo 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. |
| truncated | No | True when results were capped by the limit parameter and more events remain. totalCount carries the full match count when available, and nextOffset the input for the following page. |
| nextOffset | No | Value 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. |
| totalCount | No | Total events matching the query before the limit was applied. Fetched via a follow-up count query when results are truncated at the limit; absent otherwise. |
| ignoredFilters | No | USGS-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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), the description reveals result cap (20k), default time window (30 days), source-specific filter behavior, radius conversion, and performance implications. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured. Front-loaded with purpose and key constraints. Every sentence adds value—no redundancy. Efficiently covers source differences, parameter groupings, warnings, and best practices.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully addresses complexity: 15 parameters, two sources, output schema exists. Covers interactions (lat/lon/radius required together), defaults, source-specific behavior, and performance. No gaps for an agent to misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even with 100% schema description coverage, the description adds valuable context: magnitude thresholds (M2.5 felt, M5 damage), depth effects, PAGER meaning, significance score scaling, and EMSC radius conversion. These enrich the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool searches earthquakes by multiple criteria (time, magnitude, depth, location, alert level, felt reports) and distinguishes between USGS and EMSC sources. It also differentiates from siblings by mentioning the cap of 20,000 events and the recommendation to use earthquake_count first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: use earthquake_count to gauge result size, explains that USGS-specific filters are ignored with EMSC, and notes that large limits cause slow responses. It also specifies that lat/lon/radius must be used together.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!