Skip to main content
Glama
sepehr071

iran-quake-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Search earthquakes

eq_search
Read-onlyIdempotent

Search earthquakes in Iran by date range, magnitude, bounding box, or place text to retrieve historical and recent seismic events, filtered by province and source.

Instructions

Search earthquakes in Iran by date range, magnitude, bounding box and place text.

Use for history ("M5+ in 2026", "quakes near Bam"). USGS and EMSC have no province field: USGS gives the nearest town ('70 km NNE of Minab, Iran'), EMSC a region ('SOUTHERN IRAN'); filter by place (a province name works) or bbox. source='irsc' only knows its latest ~20 events, so older dates give more=true with few rows. Times: time_utc and time_tehran (UTC+03:30); depth_km in km. more = more results may exist beyond limit (or beyond the newest 500 events scanned when filtering by place/iran_only: narrow the dates or bbox).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bboxNoBox 'min_lat,min_lon,max_lat,max_lon', e.g. '35,50,36,52' (Tehran area). Default: all Iran.
limitNoMax events to return, 1-50 (a reply stays under 15 KB), e.g. 20.
orderNo'time' (newest first, default) or 'magnitude' (largest first).time
placeNoText the place must contain, case and accents ignored, e.g. 'Minab' or 'southern iran' (EMSC region); IRSC places are 'Town, Province'. A province name (Tehran, Kerman, Hormozgan, Khuzestan, Fars, Sistan and Baluchestan, Kermanshah, Razavi Khorasan, East Azerbaijan, West Azerbaijan, Bushehr, Mazandaran) selects its approximate box instead. English names only.
sourceNoData 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.usgs
end_dateNoEnd, UTC, same format, e.g. '2026-10-15' (a date alone includes that whole day). Default: now.
iran_onlyNoTrue (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.
start_dateYesStart, UTC: 'YYYY-MM-DD' or 'YYYY-MM-DDTHH:MM:SS', e.g. '2026-10-01'.
max_magnitudeNoMaximum magnitude, e.g. 6.
min_magnitudeNoMinimum magnitude, e.g. 4.5.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already mark this safe/idempotent/open-world, so the description correctly spends its budget on non-obvious behavior: USGS/EMSC lack a province field, IRSC keeps only ~20 events, `more` semantics including the newest-500-event scan cap, UTC vs Tehran time fields, and depth units. This is exactly the extra context that annotations cannot convey.

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?

Front-loaded with purpose and use cases, then grouped caveats. Dense and mostly earned, though the second paragraph stacks several distinct warnings (source limits, time fields, `more` semantics) that could be tightened into a cleaner list.

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?

With 10 parameters, no output schema and rich source-dependent behavior, the description covers the gaps an agent needs: partial-result signalling via `more`, which returned fields exist, and how source choice changes filtering. Nothing essential to calling it correctly is missing.

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 baseline is 3. The description mostly restates what the schema already documents (place matching, bbox default of all Iran, source enum meanings); the genuinely additive lines (cross-source field differences, IRSC's recency window) are behavioral rather than parameter semantics.

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 (Search), resource (earthquakes), scope (in Iran) and the four filter dimensions (date range, magnitude, bbox, place). The sibling set (eq_latest, eq_significant, eq_detail, eq_stats) is implicitly differentiated: this is the historical/filtered query tool, not latest/significant/detail/stats.

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 explicit use cases ('Use for history: "M5+ in 2026", "quakes near Bam"') and practical caveats (source='irsc' only has ~20 latest events; narrow dates or bbox when more=true). It does not, however, name the sibling tools it should be preferred over (eq_latest, eq_significant), so the routing guidance is one-sided.

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