Skip to main content
Glama
Sign In
iran-quake-mcp

iran-quake-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Significant earthquakes

eq_significant
Read-onlyIdempotent

Retrieve recent earthquakes in Iran ordered by magnitude to identify significant events over a specified period, with filters for magnitude threshold and data source.

Instructions

List the strongest recent earthquakes in Iran, largest magnitude first.

Use for "biggest earthquakes this month/year".

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "eq_significant"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNoLook back, days.
limitNoMax events, 1-50.
sourceNo'usgs' (default), 'emsc' or 'irsc' (Iranian Seismological Center, latest ~20 events only).usgs
iran_onlyNoTrue: only events inside Iran (outline plus place text, incl. its waters). False: whole bounding box.
min_magnitudeNoMinimum magnitude.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.2.0
    • changedInput schema / properties / days / description
      Previous value: -"Look back this many days, e.g. 30."New value: +"Look back, days."
    • changedInput schema / properties / iran_only / description
      Previous value: -"True (default): keep only events inside a coarse Iran outline (lat/lon, includes Iranian waters) whose place text names Iran (or Persian Gulf, Gulf of Oman, Caspian Sea); neighbours across the border are dropped. False: everything in the bounding box."New value: +"True: only events inside Iran (outline plus place text, incl. its waters). False: whole bounding box."
    • changedInput schema / properties / limit / description
      Previous value: -"Max events to return, 1-50, e.g. 10."New value: +"Max events, 1-50."
    • changedInput schema / properties / min_magnitude / description
      Previous value: -"Minimum magnitude, e.g. 5.0."New value: +"Minimum magnitude."
    • changedInput schema / properties / source / description
      Previous value: -"Data source: 'usgs' (USGS ComCat, default), 'emsc' (EMSC via SeismicPortal) or 'irsc' (Iranian Seismological Center, only its latest ~20 events, with province names). Magnitudes and locations differ slightly between them; ids are not interchangeable."New value: +"'usgs' (default), 'emsc' or 'irsc' (Iranian Seismological Center, latest ~20 events only)."
  2. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description's marginal contribution is the result ordering ('largest magnitude first') and the Iran scoping. It omits notable behavior the schema hints at, such as the irsc source returning only ~20 recent events and the defaults of 30 days / magnitude 5, so an agent gets no prose on data completeness caveats.

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?

Two short sentences with the core scope and ordering front-loaded and a separate usage line; nothing is padded. It is arguably too terse given five tunable parameters, but no sentence is wasted.

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?

For a read-only listing tool with full annotation coverage and a fully described schema but no output schema, the description supplies enough to select and call it. Missing only prose about default window/magnitude and the multi-source behavior, which the schema partially covers.

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 description coverage is 100%, so every parameter is already documented in structured form; baseline 3 applies. The description only implicitly reinforces iran_only (via 'in Iran') and the magnitude-based ordering, adding no syntax or interplay detail beyond the schema.

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?

States a specific verb and resource ('List the strongest recent earthquakes in Iran') plus a sort order ('largest magnitude first'), which an agent can act on directly. It does not explicitly contrast itself with eq_latest or eq_search, so the boundary with those siblings must be inferred from 'strongest' vs 'latest'.

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?

Provides a concrete trigger phrase ('Use for "biggest earthquakes this month/year"') that maps user intent to this tool. It stops short of naming alternatives (eq_search, eq_latest) or stating when NOT to use it, which keeps it below the top band.

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

Deploy Server

Other Tools