Skip to main content
Glama
enesjakozh
blake365

Claude MCP Server for USGS Quakes API

by blake365
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

USGS-Terremotos-MCP

insignia de herrería Servidor Claude MCP para la API de terremotos del USGS

Una implementación de servidor MCP para proporcionar acceso a la API de terremotos del USGS dentro de Claude Desktop .

Descripción general

Este servidor de Protocolo de Contexto de Modelo (MCP) permite que los asistentes y aplicaciones de IA:

  • Obtenga datos de terremotos a través de una amplia variedad de parámetros de búsqueda

  • Obtenga detalles sobre un terremoto específico

Los usuarios pueden ejecutar consultas utilizando lenguaje natural.

Related MCP server: earthquake-mcp-server

Salida de muestra

P: ¿Se encontraron terremotos de magnitud superior a 2 en Florida durante los últimos 20 años?

A: Te ayudaré a buscar terremotos en Florida con una magnitud mayor a 2.0 en los últimos 20 años.

Ver resultados de find-earthquakes de usgs-quakes (local)

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

Según los datos de terremotos del USGS, ha habido tres terremotos notables en Florida o cerca de allí en los últimos 20 años:

  1. Un terremoto de magnitud 5,9 en el Golfo de México el 10 de septiembre de 2006 Ubicado en alta mar en las coordenadas 26.319°N, 86.606°O Profundidad: 14 km Este fue el terremoto más grande en la región durante este período Se sintió ampliamente, con 5.763 personas reportando haber sentido el terremoto

  2. Un terremoto de magnitud 2.8 cerca de Jay, Florida, el 6 de marzo de 2019 Ubicado en las coordenadas 30.9718°N, 87.1719°O Profundidad: 5 km 49 personas informaron haber sentido este terremoto

  3. Un terremoto de magnitud 2,7 cerca de Century, Florida, el 24 de marzo de 2019 Ubicado en las coordenadas 30.9622°N, 87.2384°O Profundidad: 5 km 4 personas informaron haber sentido este terremoto

Cabe destacar que Florida experimenta relativamente pocos terremotos en comparación con regiones con mayor actividad sísmica de Estados Unidos. Los dos terremotos de 2019 ocurrieron en el Panhandle de Florida, mientras que el terremoto más grande de 2006 se produjo en alta mar, en el Golfo de México.

P: Obtenga los detalles del terremoto de Jay Florida

R: Obtendré la información detallada sobre el terremoto de magnitud 2,8 que ocurrió cerca de Jay, Florida.

Ver resultados de find-earthquake-details de usgs-quakes (local)

{
  "eventid": "us1000jbw4"
}

Aquí están los detalles clave sobre el terremoto de Jay, Florida: Fecha y hora: 7 de marzo de 2019, a las 04:45:52 UTC Ubicación: 2 km (1,2 millas) al noroeste de Jay, Florida Coordenadas: 30.9718°N, 87.1719°O Profundidad: 5 kilómetros (3,1 millas) Magnitud: 2,8 mb_lg (magnitud de onda corporal)

Detalles adicionales:

  • 49 personas reportaron haber sentido el sismo

  • El Mapa de Intensidad de Internet Comunitaria (CIIM) mostró una intensidad máxima de 2,7

  • No se generó ningún tsunami

  • El terremoto fue revisado y confirmado por científicos del USGS.

  • La ubicación tenía un margen de error horizontal de aproximadamente 6,2 km.

  • El cálculo de magnitud utilizó datos de 11 estaciones sísmicas.

  • El terremoto también fue detectado por la red sísmica de Nuevo México (NM), que calculó una magnitud ligeramente diferente de 2,63.

Medidas técnicas:

  • Brecha azimutal: 243 grados (indica una cobertura moderada por parte de las estaciones sísmicas)

  • Error RMS: 0,59 (indica una calidad razonable de la estimación de la ubicación)

  • Distancia mínima a la estación más cercana: 0,222 grados

  • Error estándar de magnitud: 0,154

Este fue un terremoto relativamente leve, pero notable en Florida, donde rara vez se registra actividad sísmica. El hecho de que lo sintieran 49 personas sugiere que fue perceptible para los residentes de la zona, aunque no se esperarían daños significativos de un terremoto de esta magnitud.

Instalación

Instalación mediante herrería

Para instalar USGS Earthquake Data para Claude Desktop automáticamente a través de Smithery :

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

Instalación manual

Instalar esto puede ser complicado si no está familiarizado con Node.js y el protocolo MCP.

  1. Instalar Node.js

  2. Clona este repositorio en una carpeta en tu máquina local

  3. El servidor ya está construido, por lo que puedes omitir el paso de compilación.

Pasos adicionales

Si desea realizar cambios en el servidor, puede hacerlo editando el archivo src/index.ts .

  • Ejecute npm install para instalar las dependencias

  • Ejecute npm run build para compilar el servidor

  • Salga y reinicie Claude Desktop después de realizar cambios

Conectando con Claude Desktop

  1. Abra la configuración de Claude Desktop en:

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

    • Ventanas: %APPDATA%\Claude\claude_desktop_config.json

  2. Agregue la configuración del servidor:

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

  1. Cierre/Salga y luego reinicie Claude Desktop

Al reiniciar, debería ver un pequeño icono de martillo en la esquina inferior derecha del cuadro de texto. Si pasa el cursor sobre él, verá la cantidad de herramientas MCP disponibles.

Solución de problemas

Si se producen errores al ejecutar el servidor, es posible que deba proporcionar la ruta completa del comando node . Por ejemplo, en 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