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.7/5 across 4 of 4 tools scored.
Each tool targets a distinct operation: counting, fetching a single event by ID, retrieving real-time feeds, and performing filtered searches. There is no overlap or ambiguity.
All tools use snake_case and the common prefix 'earthquake_', but the verbs are not uniformly structured: two use 'get_', one uses a bare verb ('count'), and one uses a noun as verb ('search'). This minor inconsistency slightly detracts from a perfect pattern.
Four tools cover the core needs for an earthquake data server: counting, detail, real-time feeds, and search. This is a well-scoped, focused set without unnecessary bloat.
The tools provide complete coverage for querying earthquake data: statistical counts, individual event details, curated real-time feeds, and flexible filtered searches across catalogs. No obvious gaps for the intended domain.
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. |
| 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 provide readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context: the feeds are CDN-cached, faster, and more available; explains the 'all' tier includes microseisms; and points out that the 'significant' tier is based on a USGS curation, not just magnitude. 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?
The description is concise (3 sentences) and front-loaded with the primary action. Every sentence provides essential information without redundancy or 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 the tool has an output schema and the input schema is fully documented, the description covers all necessary context: use cases, performance characteristics, data volume expectations, and alternatives. No gaps are apparent.
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%, and the description goes beyond by explaining the meaning of each enum value (e.g., 'all' includes microseisms, '1.0' is M1.0+, 'significant' is a curated selection). For time_window, it provides typical event count expectations (hour: 0-10, month: >10,000 for 'all'). This adds significant semantic value.
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 USGS earthquake feeds by magnitude tier and time window, using specific verbs and resources. It distinguishes from the sibling tool 'earthquake_search' by noting that these feeds are pre-computed for real-time queries, not for historical or filtered searches.
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 explicit guidance on when to use this tool ('what's happening now' queries) and when to use the alternative (earthquake_search for historical/filtered queries). It also notes performance and data volume characteristics (CDN-cached, event counts per time window) to aid 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. |
| 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. |
| total_count | No | Total events matching the query before the limit was applied. Absent when the upstream API does not report total count. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, etc. The description adds useful behavioral details: result cap at 20,000, large limit slowness, source-specific metadata differences, and conversion for EMSC radius. 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 single paragraph with clear front-loading of purpose. Every sentence adds value without redundancy. Efficiently covers all critical aspects.
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 high complexity (15 params) and existing output schema, the description is thorough. It explains source differences, usage guidelines, result limits, and relationship to siblings. Could add slight more on output structure, but output schema covers that.
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 rich context beyond schema descriptions (e.g., radius in km explained with real-world examples, magnitude impact levels, significance score range). Enhances understanding of parameter meaning.
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 it searches earthquakes by multiple criteria (time, magnitude, depth, location, PAGER, felt reports) and distinguishes itself from siblings like earthquake_count (counting) and earthquake_get_event (single event).
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 instructs to provide lat/lon/radius together for location queries, notes source-specific filter behavior, and recommends using earthquake_count first to gauge result size. Provides clear context for when to use each source.
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!