Skip to main content
Glama
enesjakozh
blake365

Claude MCP Server for USGS Quakes API

by blake365
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

美国地质调查局地震-MCP

铁匠徽章用于 USGS Quakes API 的 Claude MCP 服务器

MCP 服务器实现用于在Claude Desktop内提供对USGS Quakes API 的访问。

概述

该模型上下文协议 (MCP) 服务器使 AI 助手和应用程序能够：

  • 通过多种搜索参数获取地震数据

  • 获取有关特定地震的详细信息

用户可以使用自然语言运行查询。

Related MCP server: earthquake-mcp-server

示例输出

问：查找过去20年佛罗里达州发生的2级以上地震

**A：**我帮你搜索过去20年佛罗里达州发生的2.0级以上的地震。

查看来自 usgs-quakes (local) 的 find-earthquakes 的结果

{
  "endTime": "2024-12-28T23:59:59",
  "startTime": "2004-12-28T00:00:00",
  "maxLatitude": 31.000888,
  "minLatitude": 24.396308,
  "maxLongitude": -80.031362,
  "minLongitude": -87.634896,
  "minmagnitude": 2
}

根据美国地质调查局的地震数据，过去 20 年内佛罗里达州及其附近地区发生过三次重大地震：

  1. 2006 年 9 月 10 日，墨西哥湾发生 5.9 级地震，位于北纬 26.319°、西经 86.606° 附近，深度：14 公里，这是该地区在此期间发生的最大地震，震感强烈，共有 5,763 人报告有震感

  2. 2019 年 3 月 6 日，佛罗里达州杰伊附近发生 2.8 级地震，位于北纬 30.9718°，西经 87.1719°，深度：5 公里，49 人报告感受到此次地震

  3. 2019 年 3 月 24 日，佛罗里达州世纪附近发生 2.7 级地震，位于北纬 30.9622°，西经 87.2384°，深度：5 公里，4 人报告感受到此次地震

值得注意的是，与美国地震活跃度更高的地区相比，佛罗里达州的地震相对较少。2019年的两次地震都发生在佛罗里达州狭长地带，而2006年规模更大的地震则发生在墨西哥湾近海。

问：了解佛罗里达杰伊地震的详细信息

**A：**我将获取有关佛罗里达州杰伊附近发生的 2.8 级地震的详细信息。

查看来自 usgs-quakes (local) 的 find-earthquake-details 的结果

{
  "eventid": "us1000jbw4"
}

以下是有关佛罗里达州杰伊地震的关键细节：日期和时间：2019 年 3 月 7 日，世界标准时间 04:45:52 位置：佛罗里达州杰伊西北 2 公里（1.2 英里）坐标：北纬 30.9718°，西经 87.1719°深度：5 公里（3.1 英里）震级：2.8 mb_lg（体波震级）

其他详细信息：

  • 49人报告感受到地震

  • 社区互联网强度图 (CIIM) 显示最大强度为 2.7

  • 没有发生海啸

  • 美国地质调查局的科学家审查并确认了此次地震

  • 该位置的水平误差约为 6.2 公里

  • 震级计算使用了来自 11 个地震台站的数据

  • 新墨西哥州地震网络 (NM) 也检测到了这次地震，其计算出的震级略有不同，为 2.63 级

技术测量：

  • 方位角差距：243度（表示地震台站覆盖范围适中）

  • RMS 误差：0.59（表明位置估计的质量合理）

  • 距最近车站的最小距离：0.222度

  • 震级标准误差：0.154

这场地震规模相对较小，但对于很少经历地震活动的佛罗里达州来说，却意义非凡。49人有震感，这表明附近居民能够感受到震感，不过这种震级的地震预计不会造成重大损失。

安装

通过 Smithery 安装

要通过Smithery自动为 Claude Desktop 安装 USGS 地震数据：

npx -y @smithery/cli install @blake365/usgs-quakes-mcp --client claude

手动安装

如果您不熟悉 Node.js 和 MCP 协议，安装可能会比较棘手。

  1. 安装Node.js

  2. 将此存储库克隆到本地计算机上的文件夹

  3. 服务器已经构建，因此您可以跳过构建步骤。

额外步骤

如果您想更改服务器，您可以通过编辑src/index.ts文件来实现。

  • 运行npm install来安装依赖项

  • 运行npm run build来构建服务器

  • 更改后退出并重新启动 Claude Desktop

与 Claude Desktop 连接

  1. 打开您的 Claude Desktop 配置：

    • macOS： ~/Library/Application Support/Claude/claude_desktop_config.json

    • Windows： %APPDATA%\Claude\claude_desktop_config.json

  2. 添加服务器配置：

{
    "mcpServers": {
        "usgs-quakes": {
            "command": "node",
            "args": [
                "/Full/Route/to/Folder/usgs-quakes/build/index.js"
            ]
        }
    }
}

  1. 关闭/退出然后重新启动 Claude Desktop

重新启动后，您会在文本框的右下角看到一个小锤子图标。将鼠标悬停在该图标上，您将看到可用的 MCP 工具数量。

故障排除

如果在运行服务器时遇到错误，可能需要提供node命令的完整路径。例如，在 macOS 上： /usr/local/bin/node

Available Tools

3 tools
count-earthquakesCount EarthquakesA
Read-only

Count earthquakes matching the given search parameters, without returning the events themselves. Useful for sizing a query before running it.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of events to return (service maximum 20000)
endTimeNoLimit to events on or before this end time. Times use ISO8601 Date/Time format. Unless a timezone is specified, UTC is assumed. Defaults to NOW.
orderbyNoSort order. Defaults to time, most recent first.
latitudeNoLatitude for a circular radius search
maxdepthNoLimit to events shallower than this, in kilometres
mindepthNoLimit to events deeper than this, in kilometres
longitudeNoLongitude for a circular radius search
startTimeNoLimit to events on or after this start time. Times use ISO8601 Date/Time format. Unless a timezone is specified, UTC is assumed. Defaults to NOW - 30 days.
maxLatitudeNoNorthern edge of a search rectangle. Minimum values must be less than maximum values. Requests that use both a rectangle and a circle return the intersection, which may be empty.
maxradiuskmNoLimit to events within this many kilometres of the latitude/longitude point
minLatitudeNoSouthern edge of a search rectangle. Minimum values must be less than maximum values. Requests that use both a rectangle and a circle return the intersection, which may be empty.
maxLongitudeNoEastern edge of a search rectangle. Minimum values must be less than maximum values. Requests that use both a rectangle and a circle return the intersection, which may be empty.
maxmagnitudeNoLimit to events with at most this magnitude
minLongitudeNoWestern edge of a search rectangle. Rectangles may cross the date line using minLongitude < -180 or maxLongitude > 180. Minimum values must be less than maximum values. Requests that use both a rectangle and a circle return the intersection, which may be empty.
minmagnitudeNoLimit to events with at least this magnitude

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the description adds value by stating 'without returning the events themselves' and positioning the tool for sizing queries. This clarifies the tool's read-only, summary nature beyond what annotations alone provide.

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?

Two sentences, each earning its place: first states the action, second provides usage context. No filler, front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the action and usage context but does not specify the return format (e.g., returns a number). Since no output schema exists, this omission leaves the agent guessing what the output looks like. Adequate but not complete.

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?

Input schema coverage is 100%, with all 15 parameters having descriptions. The description adds no additional parameter-level information beyond 'matching the given search parameters.' Baseline of 3 is appropriate.

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 clearly states the verb 'Count' and the resource 'earthquakes', and specifies that it does not return events, distinguishing it from sibling tool 'find-earthquakes' which likely returns events. This makes the purpose unmistakable.

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 provides explicit guidance: 'Useful for sizing a query before running it.' This implies the tool should be used before a search query to gauge result size, and contrasts with sibling tools that return data. However, it doesn't explicitly state when not to use it or name alternatives directly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find-earthquake-detailsFind Earthquake DetailsA
Read-only

Get detailed information about a single earthquake, including origin quality metrics, by its USGS event id (e.g. 'us6000d3zh').

ParametersJSON Schema
NameRequiredDescriptionDefault
eventidYesThe USGS earthquake event id

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark readOnlyHint=true and openWorldHint=true, so the description doesn't need to emphasize safe read behavior. It adds that the tool returns 'origin quality metrics', a useful detail beyond annotations, but does not mention pagination, response size, or whether all fields are always present.

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 a single, clear sentence with an example inline. Every word is meaningful and there is no filler. Highly front-loaded: key action and parameter type stated immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has only 1 parameter, full schema coverage, and informative annotations, the description is nearly complete for a lookup tool. It could mention whether the response is synchronous or if the ID format is always lowercase, but overall it is largely sufficient.

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?

Schema coverage is 100%; the schema already defines eventid as a string with a description. The description adds a concrete example ('us6000d3zh') which aids understanding, but doesn't add deeper semantics beyond what the schema provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets detailed information for a single earthquake using a specific USGS event ID. The verb 'Get' and resource 'detailed information' are specific, and the example helps differentiate from sibling tools like find-earthquakes which likely return lists.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when you have a specific event ID, but it does not explicitly state when not to use it or contrast with count-earthquakes. The sibling tools exist but no direct guidance on trade-offs is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find-earthquakesFind EarthquakesB
Read-only

Search the USGS earthquake catalog by time, location, magnitude, and depth. Returns a summary of each matching event.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of events to return (service maximum 20000)
endTimeNoLimit to events on or before this end time. Times use ISO8601 Date/Time format. Unless a timezone is specified, UTC is assumed. Defaults to NOW.
orderbyNoSort order. Defaults to time, most recent first.
latitudeNoLatitude for a circular radius search
maxdepthNoLimit to events shallower than this, in kilometres
mindepthNoLimit to events deeper than this, in kilometres
longitudeNoLongitude for a circular radius search
startTimeNoLimit to events on or after this start time. Times use ISO8601 Date/Time format. Unless a timezone is specified, UTC is assumed. Defaults to NOW - 30 days.
maxLatitudeNoNorthern edge of a search rectangle. Minimum values must be less than maximum values. Requests that use both a rectangle and a circle return the intersection, which may be empty.
maxradiuskmNoLimit to events within this many kilometres of the latitude/longitude point
minLatitudeNoSouthern edge of a search rectangle. Minimum values must be less than maximum values. Requests that use both a rectangle and a circle return the intersection, which may be empty.
maxLongitudeNoEastern edge of a search rectangle. Minimum values must be less than maximum values. Requests that use both a rectangle and a circle return the intersection, which may be empty.
maxmagnitudeNoLimit to events with at most this magnitude
minLongitudeNoWestern edge of a search rectangle. Rectangles may cross the date line using minLongitude < -180 or maxLongitude > 180. Minimum values must be less than maximum values. Requests that use both a rectangle and a circle return the intersection, which may be empty.
minmagnitudeNoLimit to events with at least this magnitude

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true (safe read) and openWorldHint=true (data may change). The description adds that it returns a 'summary' (concise, not full detail) and confirms parameters are filters. Bar is lower due to annotations; description adds small value but doesn't explain things like rate limits, pagination, or whether results are sorted by default (the schema says orderby defaults to 'time').

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?

Short single sentence that is front-loaded with the key action ('Search the USGS earthquake catalog...'). No filler or redundancy. Could be slightly improved by noting the return type, but overall concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high complexity (15 params, no output schema, rectangle/circle interaction), the description is incomplete. It does not explain return format or behavior beyond 'summary', nor does it document the rectangle-circle intersection behavior visible in the schema. The annotations add value but the description should compensate more for the missing output schema. A 3 reflects this gap.

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 schema already has 100% description coverage with detailed explanations for all 15 parameters (e.g., ISO8601 format for time, units for depth/radius, circular vs rectangle logic). The description adds minimal meaning beyond 'earthquake catalog' context. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches the USGS earthquake catalog by specific criteria (time, location, magnitude, depth) and returns a summary. It distinguishes from siblings like 'find-earthquake-details' (which likely returns full details) and 'count-earthquakes'. However, it could more explicitly contrast with these siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for searching earthquakes with given filters but provides no guidance on when to prefer this over 'find-earthquake-details' or 'count-earthquakes'. It does not mention when not to use it, e.g., for detailed event info or aggregation queries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv1.1.1
    • First observedcount-earthquakes
    • First observedfind-earthquake-details
    • First observedfind-earthquakes
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: find-earthquakes returns summaries, count-earthquakes returns counts, and find-earthquake-details returns full details for a single ID. There is no overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (find_earthquakes, count_earthquakes, find_earthquake_details) with snake_case and predictable prefixes, making them easy for an agent to understand and select.

Tool Count5/5

Three tools is ideal for a focused read-only API like the USGS earthquake catalog. Each tool serves a necessary function without redundancy or bloat.

Completeness5/5

The tool set covers the full query lifecycle: search with filtering, count before retrieval, and detailed view by ID. There are no obvious gaps given the read-only nature of the API.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches