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

iran-quake-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Latest earthquakes

eq_latest
Read-onlyIdempotent

List recent earthquakes in Iran in reverse chronological order, filtered by hours, magnitude, source, and Iran-only bounds.

Instructions

List the most recent earthquakes in Iran, newest first.

Use for "was there an earthquake today?". Call eq_detail with an id for more.

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

Input Schema

NameRequiredDescriptionDefault
hoursNoLook back, hours.
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 / hours / description
      Previous value: -"Look back this many hours, e.g. 24."New value: +"Look back, hours."
    • 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 (a reply stays under 15 KB), e.g. 20."New value: +"Max events, 1-50."
    • changedInput schema / properties / min_magnitude / description
      Previous value: -"Minimum magnitude, e.g. 3.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.8/5.0
Behavior3/5

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

The annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds useful context about geographic scope and newest-first ordering, but does not disclose return contents, pagination behavior, or source coverage limits beyond what the schema states.

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 short sentences, front-loaded with the core purpose and followed by a concrete use case and a pointer to eq_detail. There is no unnecessary wording.

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 simple read-only listing tool with five fully described parameters and clear annotations, the description gives enough to select and invoke it correctly. It could mention the return shape or pagination, but the lack of an output schema makes this a minor 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?

Schema description coverage is 100%, so the schema fully documents parameters such as hours, limit, source, iran_only, and min_magnitude. The description reinforces Iran scope and recency ordering but adds no parameter-level meaning 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?

The description states a specific verb, resource, geographic scope, and ordering: 'List the most recent earthquakes in Iran, newest first.' It clearly identifies the tool's purpose, though it only differentiates from eq_detail and not from siblings such as eq_search or eq_significant.

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?

It provides a concrete usage trigger, 'Use for "was there an earthquake today?"', and routes the agent to eq_detail for more information. However, it does not explain when to prefer eq_search, eq_significant, or eq_stats instead.

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