A
licenseA
qualityD
maintenanceReal-time earthquake data and seismic monitoring for AI agents via the USGS Earthquake Catalog API.
8
MIT
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
- Server Listing
- earthquake-mcp-server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
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.
100% free. Your data is private.
Tool Definition Quality
A4.6/5.0
Tool DescriptionsA
Average 4.7/5 across 4 of 4 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool serves a clearly distinct purpose: count for aggregate stats, search for querying events, get_feed for real-time feeds, and get_event for single-event detail. Even though search and feed both return event lists, their use cases are explicitly separated by temporal scope and filtering, making confusion unlikely.
Naming Consistency5/5
All tools follow the consistent prefix 'earthquake_' followed by an action verb: count, get_event, get_feed, search. The pattern is uniform and predictable, making it easy to anticipate tool functionality from names alone.
Tool Count5/5
Four tools is well-scoped for a read-only earthquake data server. Each tool covers a distinct aspect of data access (statistics, query, real-time feed, detail), and the count is neither excessive nor insufficient.
Completeness4/5
The tool surface covers the core workflows: searching, counting, retrieving real-time feeds, and getting event details. A minor gap is the lack of EMSC-specific event details, but for the primary domain (USGS data) the coverage is strong and no critical operations are missing.
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.
ParametersJSON Schema
| 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
ParametersJSON 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
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds substantial beyond-annotation behavior: the 30-day default window, exceeds_limit/truncation implications, USGS vs EMSC max_allowed differences, inclusion of quarry blasts, and ignoredFilters behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence adds unique information. It is front-loaded with purpose and usage, then progressively discloses caveats and cross-source differences. There is no fluff or repetition of schema-visible details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 parameters, 2 data sources, and an output schema, the description covers all critical operational nuances: time-window behavior, truncation cap, source-specific filter handling, and catalog content differences. It explains enough for an agent to safely choose and invoke the tool without surprise.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description meaningfully augments parameter meaning. It clarifies start_time default (30 days), event_type matching ('verbatim... returns zero'), radius_km conversion for EMSC, and which USGS-only filters get ignored on EMSC. This adds value beyond the schema's individual field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Count earthquakes matching filters without fetching full records', using a specific verb ('Count') and resource ('earthquakes'). It explicitly contrasts with fetching full records, distinguishing it from sibling earthquake_search. The examples ('how many M5+ earthquakes in 2025?') further clarify its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use: 'statistical queries' or 'to gauge result size before calling earthquake_search', naming the alternative tool. It provides exclusions and caveats: warns about the 30-day default, the exceeds_limit truncation, and non-tectonic records. This gives clear when-to-use and when-not-to-use guidance.
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.
ParametersJSON Schema
| 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
ParametersJSON 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
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/idempotent annotations, the description adds critical behavioral context: products are omitted when USGS produced none, with small automatic events typically empty and large reviewed events having most products. It also states the USGS-only limitation, which affects availability and expected results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then efficiently enumerates the analysis products, variability, and ID source. It is detailed but all sentences earn their place, and the logical flow makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter interface and a rich output schema, the description thoroughly covers how to obtain an event ID, what products the response contains, and when those products may be absent. It also addresses the provider limitation, making it complete within its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents event_id with a clear description, example, and source, achieving 100% schema coverage. The description's mention of where IDs come from is helpful but largely redundant with the schema, so it adds only marginal extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it fetches detail for a specific earthquake by USGS event ID, a specific verb+resource action. It distinguishes itself from sibling list/search tools by noting it returns the same normalized event plus additional single-event-only products, and it clarifies the USGS-only scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly points to earthquake_get_feed and earthquake_search results as the source for event IDs, and warns that EMSC events have no per-event detail endpoint. It implicitly conveys when to use this tool (when you have a specific event ID and need full detail), though it doesn't explicitly name alternative tools for other scenarios.
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.
ParametersJSON Schema
| 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
ParametersJSON 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
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/idempotent annotations, the description discloses CDN caching, approximate one-minute regeneration, pagination via cursor, and warns that numeric offsets will skip or repeat events. These are valuable behavioral traits not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately detailed without redundancy. Each sentence adds a distinct piece of information: purpose, rationale, tier explanations, paging behavior, cursor warning, and alternative guidance. The structure is logical and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with this complexity (paging, curatorship, multiple tiers) and an output schema present, the description fully covers purpose, use cases, paging mechanics, parameter interpretations, and alternatives. No critical operational detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds semantic value by explaining the meaning of 'significant' as curated, 'all' as including microseisms, and cursor restrictions ('opaque and must be passed back verbatim'). It also clarifies that limit applies to the first page only, which is not stated in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Fetch a USGS pre-computed real-time earthquake feed by magnitude tier and time window' with a specific verb and resource. It differentiates from sibling tools by naming earthquake_search as the alternative 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The text clearly states when to use this tool ('use them for "what's happening now" queries') and provides explicit alternatives ('For historical or filtered queries, use earthquake_search instead'). It also recommends specific time windows for real-time checks ('Prefer "hour" or "day"').
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.
ParametersJSON Schema
| 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
ParametersJSON 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
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds substantial behavioral detail: non-tectonic records (quarry blasts, explosions) exist, USGS-specific filters are ignored for EMSC and reported in ignoredFilters, a single call caps at 20,000 events, and pagination uses nextOffset and totalCount. These are non-obvious behaviors beyond the annotations, making the tool's runtime behavior highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense paragraph that front-loads the purpose and progresses logically through source comparison, filtering caveats, usage advice, and pagination. It is longer than average, but every sentence conveys necessary information for a tool with 17 parameters. It could be slightly better structured with bullet points, but it remains efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex search tool with an output schema, the description covers all essential aspects: data sources, filter compatibility, location parameter dependencies, paging behavior, and a pointer to the count sibling. The presence of an output schema means return field details are not necessary. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage for all 17 parameters. The description adds valuable context not present in the schema: e.g., why event_type='earthquake' filters non-tectonic records, the distinction between USGS and EMSC filter applicability, and the meaning of nextOffset/totalCount in paging. This enhances parameter semantics without over-repeating schema content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search earthquakes by time range, magnitude, depth, location radius, PAGER alert level, or felt reports.' It clearly distinguishes this tool from siblings by mentioning earthquake_count for gauging result size, and it specifies the two data sources (USGS and EMSC), making the purpose and scope immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit alternative: 'Use earthquake_count first to gauge result size before requesting large result sets.' It also provides usage prerequisites such as 'provide latitude, longitude, and radius_km together' and explains when USGS-specific filters apply. However, it does not explicitly mention the other siblings (earthquake_get_event, earthquake_get_feed) as alternatives, so it's clear but not exhaustive.
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!
Related MCP Servers
- Alicense-qualityCmaintenanceProvides access to the USGS Earthquake Catalog for querying earthquake events via the FDSNWS API, enabling natural language questions about earthquake data.11MIT
- Flicense-qualityCmaintenanceEnables users to explore live earthquake data from USGS, with an interactive widget for filtering and visualizing seismic events worldwide.
- Alicense-qualityDmaintenanceIntegrates multiple earthquake data sources (IRIS, USGS, GNSS) for comprehensive seismic monitoring, analysis, and risk assessment via natural language queries.1MIT
Try in Browser
Your Connectors
Sign in to create a connector for this server.