Usgs Earthquakes

Count Earthquakes

count_earthquakes

Read-onlyIdempotent

Count earthquakes matching a filter without returning the events — fast for questions like "how many M5+ quakes in the last 7 days near X". Same filters as search_earthquakes (time, magnitude, circular area); for "last N days/hours" questions pass days/hours rather than computing start_time yourself. The response echoes the exact start_time/end_time and magnitude filter actually queried, ahead of the count itself. Keyless.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "days": 7,
      "min_magnitude": 5
    },
    "name": "count_earthquakes"
  }
}

Input Schema

Name	Required	Description
`days`	No	Trailing window length in days, measured back from the exact current time (e.g. days: 7 for "the last 7 days"). Use this instead of computing a start_time for relative-window questions — it is the only way to get an EXACT trailing window rather than a date-boundary approximation. Ignored if start_time or end_time is given. If `hours` is also given, `hours` wins.
`hours`	No	Trailing window length in hours, measured back from the exact current time (e.g. hours: 168 for "the past 168 hours"). Same precedence as `days` (ignored if start_time/end_time given); takes priority over `days` if both are given.
`end_time`	No	ISO date/time upper bound, e.g. "2026-06-09". A bare date is treated as 00:00:00 UTC that day. Defaults to now.
`latitude`	No	Center latitude for a circular search.
`longitude`	No	Center longitude for a circular search.
`start_time`	No	ISO date/time lower bound, e.g. "2026-06-01" or "2026-06-01T00:00:00". A bare date (no time) is treated as 00:00:00 UTC that day. If given, this (with end_time) takes precedence over `days`/`hours`, which are then ignored. For "in the last N days" questions, prefer `days` instead of computing this yourself — a model-guessed start_time is a common source of silently-wrong counts. Defaults to 30 days before now if start_time, days, and hours are all omitted.
`max_magnitude`	No	Maximum magnitude.
`max_radius_km`	No	Search radius in km around latitude/longitude.
`min_magnitude`	No	Minimum magnitude (e.g. 5 for M5+).

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 24, 2026

changedInput schema / examples

Previous value: -[
-  {
-    "end_time": "2026-06-09",
-    "min_magnitude": 5,
-    "start_time": "2026-05-09"
-  },
-  {
-    "latitude": 35,
-    "longitude": 139,
-    "max_radius_km": 200,
-    "min_magnitude": 6.5,
-    "start_time": "2026-01-01"
-  }
-]New value: +[
+  {
+    "days": 7,
+    "min_magnitude": 5
+  },
+  {
+    "latitude": 35,
+    "longitude": 139,
+    "max_radius_km": 200,
+    "min_magnitude": 6.5,
+    "start_time": "2026-01-01"
+  }
+]

addedInput schema / properties / days

Added value: +{
+  "description": "Trailing window length in days, measured back from the exact current time (e.g. days: 7 for \"the last 7 days\"). Use this instead of computing a start_time for relative-window questions — it is the only way to get an EXACT trailing window rather than a date-boundary approximation. Ignored if start_time or end_time is given. If `hours` is also given, `hours` wins.",
+  "type": "number"
+}

changedInput schema / properties / end_time / description

Previous value: -"ISO date/time upper bound. Defaults to now."New value: +"ISO date/time upper bound, e.g. \"2026-06-09\". A bare date is treated as 00:00:00 UTC that day. Defaults to now."

addedInput schema / properties / hours

Added value: +{
+  "description": "Trailing window length in hours, measured back from the exact current time (e.g. hours: 168 for \"the past 168 hours\"). Same precedence as `days` (ignored if start_time/end_time given); takes priority over `days` if both are given.",
+  "type": "number"
+}

changedInput schema / properties / start_time / description

Previous value: -"ISO date/time lower bound. Defaults to 30 days ago."New value: +"ISO date/time lower bound, e.g. \"2026-06-01\" or \"2026-06-01T00:00:00\". A bare date (no time) is treated as 00:00:00 UTC that day. If given, this (with end_time) takes precedence over `days`/`hours`, which are then ignored. For \"in the last N days\" questions, prefer `days` instead of computing this yourself — a model-guessed start_time is a common source of silently-wrong counts. Defaults to 30 days before now if start_time, days, and hours are all omitted."

Changed1 schema field changedJul 29, 2026

addedInput schema / examples

Added value: +[
+  {
+    "end_time": "2026-06-09",
+    "min_magnitude": 5,
+    "start_time": "2026-05-09"
+  },
+  {
+    "latitude": 35,
+    "longitude": 139,
+    "max_radius_km": 200,
+    "min_magnitude": 6.5,
+    "start_time": "2026-01-01"
+  }
+]

First observedJun 10, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds non-obvious behavior: the response echoes the exact start_time/end_time and magnitude filter actually applied before the count, and it is keyless (no auth setup). It doesn't discuss rate limits or result-size characteristics, keeping it at a 4 against the annotation baseline.

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?

Four short sentences, front-loaded with what the tool is and how it differs from siblings, then the relative-window guidance, then the response shape. No filler and nothing repeated from structured fields verbatim.

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?

Nine optional parameters, no output schema, and the description still covers the filter axes, the precedence rule for relative windows, the count-only return shape, and the keyless auth story. Nothing an agent needs to call it correctly is missing.

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?

Schema coverage is 100%, so the baseline is 3. The description adds genuine guidance beyond the schema: prefer days/hours over model-computed start_time because a guessed start_time is a common source of silently-wrong counts, and it names the three filter axes (time, magnitude, circular area).

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?

States a specific verb and resource ('Count earthquakes matching a filter without returning the events') and immediately contrasts with the event-returning siblings by saying it does NOT return events. An agent can distinguish this from search_earthquakes and get_earthquake without opening any schema.

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?

Gives a concrete usage trigger ('how many M5+ quakes in the last 7 days near X') and an explicit routing rule: use days/hours rather than computing start_time yourself. It ties itself to search_earthquakes via 'Same filters', which hints at the alternative without a fully explicit 'use search_earthquakes when you need the events' statement.

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

All Usgs Earthquakes tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.