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 if omitted. | |
| 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 (readOnlyHint, openWorldHint, idempotentHint) are present and consistent. Description adds significant context: explains USGS vs EMSC differences, field behaviors (max_allowed, ignored filters), and truncation warning. 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?
Description is 4 sentences, front-loaded with purpose. Every sentence provides necessary information without redundancy. No fluff.
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, full schema coverage, and presence of output schema, the description adequately covers purpose, usage, source differences, and truncation behavior. No missing critical information.
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%, so baseline is 3. The description adds value by noting that USGS-specific filters are ignored when source=emsc, which is not fully covered in individual parameter descriptions. This enhances 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 'Count earthquakes matching filters without fetching full records', specifying the verb 'Count', resource 'earthquakes', and contrasting with 'earthquake_search'. It includes example queries, ensuring no confusion with sibling tools.
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 states use for statistical queries and to gauge result size before calling earthquake_search. Warns about truncation when exceeds_limit is true and advises narrowing filters. Also clarifies source-specific behavior (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 indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context by listing the specific data fields returned and the USGS-only limitation. No destructive behavior is mentioned, consistent with annotations.
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 extremely concise at four sentences, each serving a clear purpose: defining the tool, listing outputs, explaining ID sourcing, and noting a limitation. No redundancy or wasted words.
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 that the tool has only one parameter, full schema coverage, a known output schema (not shown but exists), clear annotations, and a simple use case, the description covers all necessary context: what it does, what it returns, where IDs come from, and a notable exclusion (EMSC). 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?
The input schema already provides a detailed description of the event_id parameter (type, examples, source). The tool description reinforces this by mentioning event IDs appear in the 'id' field of other tools, adding minimal extra value. Schema coverage is 100%, so baseline 3 is appropriate.
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 'Fetch detail for a specific earthquake by USGS event ID' and lists the specific fields returned (DYFI, MMI, PAGER alert level, etc.). It distinguishes from sibling tools by noting that event IDs come from earthquake_get_feed and earthquake_search results.
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?
The description provides clear context for when to use this tool: after obtaining an event ID from earthquake_get_feed or earthquake_search. It also warns that EMSC events are not supported due to no per-event endpoint. However, it does not explicitly name alternatives or state when not to use it beyond the USGS-only constraint.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds behavioral context: feeds are CDN-cached (faster, more available), explains 'significant' tier curation, and provides typical event counts (0-10 for hour, >10,000 for month). No contradiction with annotations.
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?
4 sentences, front-loaded with purpose, followed by usage guidance and parameter details. Every sentence is informative with zero waste. Efficient and structured.
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 only 2 parameters, full annotations, and output schema present, the description covers all necessary context: performance characteristics, event count expectations, and distinction from sibling. Nothing missing.
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% and description adds meaning beyond schema: for 'time_window' it repeats typical counts; for 'magnitude_tier' it clarifies 'all includes microseisms' and 'significant is USGS curated, not purely magnitude-based'. This enhances 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 real-time earthquake feed by magnitude tier and time window, using specific verbs like 'Fetch'. It distinguishes from siblings by emphasizing 'pre-computed' and 'CDN-cached' vs. the query API, and explicitly contrasts with 'earthquake_search' for historical/filtered queries.
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 states when to use ('what's happening now' queries) and when not to use (historical or filtered queries, directing to 'earthquake_search'). Also provides context on event counts for different time windows, aiding agent decision-making.
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 if omitted. | |
| 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. |
| truncated | No | True when results were capped by the limit parameter and more events likely exist. Use earthquake_count to get the total match count. |
| totalCount | No | Total events matching the query before the limit was applied. Absent when the upstream API does not report a total count. |
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 behavioral details beyond annotations: mentions result cap, source-dependent filter behavior (USGS-specific ignored for EMSC), and conversion of radius_km to degrees for 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?
Four sentences: first introduces core purpose, second adds source context, third gives usage advice, fourth mentions limit. No redundant information, front-loaded with most important details.
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 complex tool with 15 parameters, high schema coverage, and an output schema (stated), the description provides all necessary context: source differences, filter behaviors, location constraints, and limit recommendation. Complete enough for an agent to use correctly.
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?
All 15 parameters have schema descriptions (100% coverage). The description enriches parameter meaning with usage context (e.g., 'M2.5+ is felt by some people', '100 km covers a metro region') and explains the effect of combining parameters like latitude, longitude, radius_km. Adds value beyond 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 verb 'search' and resource 'earthquakes', lists filtering dimensions (time, magnitude, depth, location, PAGER, felt reports), and distinguishes between USGS and EMSC sources. It also differentiates from sibling tool earthquake_count by suggesting its use for result size estimation.
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 using earthquake_count first for large result sets, explains when to use EMSC vs USGS, and specifies that source-specific filters are ignored when source is emsc. Also states result cap of 20,000 events and requirements for location parameters.
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!