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. 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). USGS-specific filters (alert_level, min_felt, min_significance) are ignored when source=emsc.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Data source. "usgs" covers global events with PAGER, DYFI, and ShakeMap metadata. "emsc" covers the European-Mediterranean 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). | |
| 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. |
| 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. |
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 felt reports count (DYFI), ShakeMap maximum intensity (MMI), PAGER alert level, tsunami flag, and magnitude type. 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. |
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. For historical or filtered queries, use earthquake_search instead.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 in the feed. |
| events | Yes | Earthquake events, newest first. |
| notice | No | Recovery guidance when the feed contains no events — suggests narrowing the magnitude tier, widening the time window, or using earthquake_search for filtered queries. Absent when the feed contains events. |
| feed_url | Yes | Source feed URL. |
| 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 (European-Mediterranean, independent catalog). For location-based queries, provide latitude, longitude, and radius_km together. USGS-specific filters (alert_level, min_felt, min_significance) are ignored when source=emsc. Use earthquake_count first to gauge result size before requesting large result sets. Results are capped at 20,000 events per query.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum events to return. Default 100. Large limits (>1000) may result in slow responses. Max 20000. | |
| source | No | Data source. "usgs" covers global events with PAGER, DYFI, and ShakeMap metadata. "emsc" covers the European-Mediterranean region with an independent catalog — useful for cross-verification or European-focused queries. | 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). | |
| 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 likely exist. totalCount carries the full match count when available. |
| 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. |
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!