{
  "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
}

USGS の地震データによると、過去 20 年間にフロリダ州またはその近辺で 3 つの注目すべき地震が発生しています。

2006年9月10日、メキシコ湾でマグニチュード5.9の地震が発生しました。発生場所：沖合、座標：北緯26.319度、西経86.606度。深さ：14km。この地震は、この時期にこの地域で発生した最大の地震でした。広範囲で感じられ、5,763人が地震を感じたと報告しています。
2019年3月6日、フロリダ州ジェイ近郊でマグニチュード2.8の地震が発生しました。発生場所：北緯30.9718度、西経87.1719度。深さ：5km。49人がこの地震を感じたと報告しています。
2019年3月24日、フロリダ州センチュリー近郊でマグニチュード2.7の地震が発生しました。発生場所：北緯30.9622度、西経87.2384度。深さ：5km。4人がこの地震を感じたと報告しています。

フロリダ州は、アメリカ合衆国の地震活動が活発な地域に比べて地震の発生頻度が比較的少ないことは注目に値します。2019年の2つの地震はフロリダ州西部で発生しましたが、2006年のより大きな地震はメキシコ湾沖で発生しました。

Q: ジェイフロリダ地震の詳細を教えてください

**A:**フロリダ州ジェイ近郊で発生したマグニチュード2.8の地震についての詳しい情報を入手します。

usgs-quakes (local) の find-earthquake-details の結果を表示

{
  "eventid": "us1000jbw4"
}

フロリダ州ジェイ地震の主な詳細は次のとおりです。日時：2019年3月7日、午前4時45分52秒（UTC）場所：フロリダ州ジェイの北西2キロメートル（1.2マイル）座標：北緯30.9718度、西経87.1719度深さ：5キロメートル（3.1マイル）マグニチュード：2.8 mb_lg（実体波マグニチュード）

追加の詳細:

49人が地震を感じたと報告
コミュニティインターネット強度マップ（CIIM）は、最大強度2.7を示した。
津波は発生しなかった
この地震はUSGSの科学者によって調査され、確認された。
この位置の水平誤差は約6.2 kmでした
マグニチュードの計算には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 プロトコルに精通していない場合、これをインストールするのは難しいかもしれません。

Node.jsをインストールする
このリポジトリをローカルマシンのフォルダにクローンします
サーバーはすでに構築されているため、ビルド手順をスキップできます。

追加の手順

サーバーに変更を加えたい場合はsrc/index.tsファイルを編集します。

npm install実行して依存関係をインストールします
npm run buildを実行してサーバーをビルドします
変更を加えたら、Claude Desktop を終了して再起動します。

Claude Desktopとの接続

Claude Desktop の構成を次の場所で開きます:
- macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
- Windows: %APPDATA%\Claude\claude_desktop_config.json
サーバー構成を追加します。

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

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

Name	Required	Description
`limit`	No	Maximum number of events to return (service maximum 20000)
`endTime`	No	Limit 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.
`orderby`	No	Sort order. Defaults to time, most recent first.
`latitude`	No	Latitude for a circular radius search
`maxdepth`	No	Limit to events shallower than this, in kilometres
`mindepth`	No	Limit to events deeper than this, in kilometres
`longitude`	No	Longitude for a circular radius search
`startTime`	No	Limit 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.
`maxLatitude`	No	Northern 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.
`maxradiuskm`	No	Limit to events within this many kilometres of the latitude/longitude point
`minLatitude`	No	Southern 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.
`maxLongitude`	No	Eastern 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.
`maxmagnitude`	No	Limit to events with at most this magnitude
`minLongitude`	No	Western 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.
`minmagnitude`	No	Limit 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

Name	Required	Description	Default
`eventid`	Yes	The 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

Name	Required	Description
`limit`	No	Maximum number of events to return (service maximum 20000)
`endTime`	No	Limit 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.
`orderby`	No	Sort order. Defaults to time, most recent first.
`latitude`	No	Latitude for a circular radius search
`maxdepth`	No	Limit to events shallower than this, in kilometres
`mindepth`	No	Limit to events deeper than this, in kilometres
`longitude`	No	Longitude for a circular radius search
`startTime`	No	Limit 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.
`maxLatitude`	No	Northern 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.
`maxradiuskm`	No	Limit to events within this many kilometres of the latitude/longitude point
`minLatitude`	No	Southern 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.
`maxLongitude`	No	Eastern 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.
`maxmagnitude`	No	Limit to events with at most this magnitude
`minLongitude`	No	Western 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.
`minmagnitude`	No	Limit 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.

3 tool updatesv1.1.1Aug 18, 2026
- 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 2026-08-18 05:10 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

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

earthquake-mcp-server A
io.github.cyanheads
Search USGS and EMSC seismic data — real-time feeds, event queries, and earthquake counts.
Government Data Open Data
421
Weather & Geo Intel MCP A
io.github.selflabbs
US weather & geo for AI agents: forecasts, alerts, earthquakes, elevation, geocoding. No keys.
Weather Services Location Services
2
Weather & Geo Intel MCP A
com.datakoot
US weather & geo for AI agents: forecasts, alerts, earthquakes, elevation, geocoding. No keys.
Weather Services Location Services
61
USGS Earthquakes A
com.olyport
Real-time earthquake events from the US Geological Survey
Government Data Open Data Search
32

Related MCP Servers

usgs-earthquakes
Government Data Open Data
pipeworx-io
A
license
Not graded
quality
B
maintenance
Provides access to the USGS Earthquake Catalog for querying earthquake events via the FDSNWS API, enabling natural language questions about earthquake data.
Updated 17 days ago (2026-09-26 22:10 UTC)
29 npm
MIT
earthquake-mcp-server
Open Data Research & Data
AiAgentKarl
A
license
A
quality
D
maintenance
Real-time earthquake data and seismic monitoring for AI agents via the USGS Earthquake Catalog API.
Updated 6 months ago (2026-04-11 07:59 UTC)
8
MIT
Context Weather
Weather Services Location Services
tjguitar2025
F
license
A
quality
D
maintenance
Integrates the US National Weather Service API with Claude Desktop, enabling users to query current conditions and forecasts using natural language.
Updated 3 months ago (2026-07-10 22:54 UTC)
2
-
athena-quake-mcp
Open Data Government Data Data Visualization
zordhalo
F
license
Not graded
quality
C
maintenance
Enables users to explore live earthquake data from USGS, with an interactive widget for filtering and visualizing seismic events worldwide.
Updated 2 months ago (2026-08-11 05:12 UTC)
-

USGS-地震-MCP

概要

サンプル出力

インストール

Smithery経由でインストール

手動インストール

追加の手順

Claude Desktopとの接続

トラブルシューティング

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches