apibase

Search EMSC Real-Time Earthquakes

emsc.seismic.search

Read-onlyIdempotent

Search the European-Mediterranean Seismological Centre (EMSC) real-time seismicity catalog (EMSC-RTS) by time range, bounding box or point+radius, magnitude range, and depth range. A distinct regional network from USGS, often lower-latency for Euro-Mediterranean events, with per-event reporting-agency attribution. Returns event ID, time, magnitude, location, depth, region name, and reporting agency for each match. Data: seismicportal.eu (EMSC), no auth required.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Maximum number of events to return, 1-200 (default 50).
`endtime`	No	End of the time window, ISO 8601 date or datetime (e.g. 2026-08-27T23:59:59). Omit for no upper bound.
`latitude`	No	Center latitude in decimal degrees for a point+radius search (use with longitude and maxradius).
`maxdepth`	No	Maximum hypocenter depth in kilometers.
`mindepth`	No	Minimum hypocenter depth in kilometers.
`longitude`	No	Center longitude in decimal degrees for a point+radius search (use with latitude and maxradius).
`maxradius`	No	Search radius in degrees around the latitude/longitude point (e.g. 5 for ~550km at the equator).
`starttime`	No	Start of the time window, ISO 8601 date or datetime (e.g. 2026-08-01 or 2026-08-01T00:00:00). Omit for no lower bound.
`maxlatitude`	No	Maximum latitude in decimal degrees for a bounding-box search (e.g. 45.0).
`minlatitude`	No	Minimum latitude in decimal degrees for a bounding-box search (e.g. 34.0).
`maxlongitude`	No	Maximum longitude in decimal degrees for a bounding-box search (e.g. 25.0).
`maxmagnitude`	No	Maximum earthquake magnitude to include (e.g. 7.0).
`minlongitude`	No	Minimum longitude in decimal degrees for a bounding-box search (e.g. 5.0).
`minmagnitude`	No	Minimum earthquake magnitude to include (e.g. 3.0).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`error`	No	Present only when the call failed. Includes error code, message, request_id, and any provider-specific extras.
`result`	No	Tool response payload. Shape varies per tool — consult the tool description and inputSchema. May be an object, array, string, or number depending on the upstream provider response.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 22, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already establish read-only, non-destructive, idempotent behavior, so the description only needs to add complementary context. It adds that no authentication is required, identifies the upstream data source (seismicportal.eu/EMSC), and notes real-time latency characteristics. No contradictions with the annotations.

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?

Three dense sentences cover function, source differentiation, return contents, data source, and auth requirement. The function statement is front-loaded and every sentence earns its place; there is no filler or repetition of schema boilerplate.

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?

Given 14 optional parameters, a rich schema with examples, and an output schema, the description supplies the remaining context an agent needs: the catalog identity, the geographic search modes, the distinction from USGS, and the fact that no auth is required. Nothing essential is missing for correct invocation.

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%, with each parameter already described in detail including examples and grouping hints such as 'for a bounding-box search' and 'use with longitude and maxradius'. The description restates the main search dimensions, which is useful orientation, but it does not add much meaning beyond the schema.

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 opens with the specific action 'Search' and names the exact resource: the EMSC real-time seismicity catalog (EMSC-RTS), listing concrete filter dimensions (time, geographic modes, magnitude, depth). It also distinguishes itself from USGS by noting it is a separate regional network, so an agent can tell it apart from other earthquake search tools.

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 gives clear selection context: it positions EMSC as a distinct regional network that is often lower-latency for Euro-Mediterranean events and offers per-event agency attribution. It does not explicitly name a sibling tool to use instead or state exact 'when-not-to-use' conditions, so it stops short of a fully explicit routing rule.

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

All apibase 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.