Skip to main content
Glama
mysukriramli

disaster-wire

by mysukriramli
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Autonomous Global Disaster Intelligence Wire & MCP Server

License: MIT MCP Server Python 3.11+

An autonomous, 100% hands-off natural disaster intelligence wire engineered specifically for consumption by AI Agents, Large Language Models (LLMs), and automated RAG pipelines via the Model Context Protocol (MCP).

The pipeline monitors physical crisis telemetry (earthquakes, tsunamis, floods, tropical cyclones, volcanic eruptions, and severe weather), strips metaphorical news using semantic LLM triage, calculates spatial geohashes, cross-references proximity to critical supply chain infrastructure, and exposes structured tools for downstream AI assistants.

🛠️ Model Context Protocol (MCP) Tools

This repository implements the Model Context Protocol (MCP) specification to provide real-time tool calling for Claude Desktop, Cursor, and custom agent runtimes.

1. list_active_disasters

Query active natural disaster events within the rolling 24–48 hour window with deterministic property filtering.

  • Arguments:

    • event_type (string, optional): Filter by event category (earthquake, tsunami, flood, cyclone, wildfire, volcanic_eruption, severe_weather).

    • severity (string, optional): Filter by alert level (minor, moderate, severe, catastrophic).

    • country (string, optional): Filter by target jurisdiction (e.g., Japan, Philippines, United States).

    • limit (integer, optional): Max incidents to return (default: 10, max: 50).

  • Returns: JSON object containing matched incidents, coordinates, geohashes, lifecycle phases, and recommended autonomous action playbooks.

2. get_disaster_by_id

Retrieve the full deterministic telemetry, impact stats, and source citations for a specific incident.

  • Arguments:

    • event_id (string, required): The unique incident identifier (e.g., usgs_nc75001234, gdacs_1002341, or news_a1b2c3d4).

  • Returns: Full JSON payload including raw sensor readings, depth, wind speed, casualty counts, and exposed infrastructure hubs.

3. find_disasters_near_coordinates

Performs geospatial radial queries using the Haversine great-circle distance formula to detect active threats around specific target locations.

  • Arguments:

    • latitude (float, required): Target latitude between -90.0 and 90.0.

    • longitude (float, required): Target longitude between -180.0 and 180.0.

    • radius_km (float, optional): Radial search perimeter in kilometers (default: 500.0).

  • Returns: Sorted list of active disasters ordered by proximity to the query coordinates, annotated with calculated distance in kilometers.

Related MCP server: datto-bcdr-mcp

📦 Client Configuration

Connecting Claude Desktop (Remote SSE)

Add the following to your claude_desktop_config.json:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "disaster-wire": {
      "url": "[https://sukriramli-disaster-wire-mcp.hf.space/gradio_api/mcp/sse](https://sukriramli-disaster-wire-mcp.hf.space/gradio_api/mcp/sse)"
    }
  }
}

Available Tools

3 tools
find_disasters_near_coordinatesA
Read-onlyIdempotent

Locate active natural disasters within a radial distance (km) of target latitude and longitude coordinates. Use when evaluating geographic hazard exposure for specific facilities, cities, ports, or data centers at known coordinates. Do not use for country-wide or categorical queries (use list_active_disasters instead) or if you already hold an event_id (use get_disaster_by_id instead). Calculates great-circle distance via Haversine formula. Results are sorted ascending by distance_from_query_km. Returns {'matched_count': 0, 'results': []} if no incidents fall within radius.

ParametersJSON Schema
NameRequiredDescriptionDefault
latitudeYesTarget latitude in decimal degrees (-90.0 to 90.0, WGS-84 standard).
longitudeYesTarget longitude in decimal degrees (-180.0 to 180.0, WGS-84 standard).
radius_kmNoRadial search perimeter measured in kilometers (km) from target coordinates (1.0 to 5000.0, defaults to 500.0 km).

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare the safe/read-only/idempotent profile, so the description's added value is the algorithm (Haversine great-circle), result ordering (ascending distance_from_query_km), and the explicit empty-result shape. It stops short of noting pagination or result caps, but the behavioral picture is strong for a bounded read-only query.

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 tight sentences: purpose first, then usage conditions, then algorithm, then output ordering and empty-case. No filler, and the most decision-relevant information (when to use / when not to) is front-loaded.

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?

For a 3-parameter, read-only spatial query with no output schema, the description covers purpose, routing, computation method, sort order, and the zero-match response contract. An agent has everything needed to call it and interpret the result.

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% and each parameter already documents units, ranges, and defaults. The description reinforces unit (km) and the radial nature of radius_km but adds no syntax or semantics beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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 (Locate) plus resource (active natural disasters) and scope (radial distance in km from coordinates). An agent can distinguish it from list_active_disasters and get_disaster_by_id purely from the text, 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly gives the use case (hazard exposure for facilities, cities, ports, data centers at known coordinates) and two named exclusions with the alternative tool to use instead in each case (country-wide/categorical, or known event_id). Nothing is left to inference.

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

get_disaster_by_idA
Read-onlyIdempotent

Retrieve comprehensive technical telemetry, impact metrics, casualty estimates, and exposed infrastructure for a specific disaster ID. Use exclusively when you already hold a valid event_id obtained from list_active_disasters or find_disasters_near_coordinates. Do not use to browse or discover active disasters (use list_active_disasters instead) or for coordinate proximity queries (use find_disasters_near_coordinates instead). Pure read-only lookup. If the requested event_id is not in the active pool, returns an {'error': '...'} JSON object without raising exceptions.

ParametersJSON Schema
NameRequiredDescriptionDefault
event_idYesUnique incident identifier string (e.g., 'usgs_nc75001234', 'gdacs_1002341', or 'news_e5f6g7h8').

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful behavioral context beyond those annotations by stating that an inactive or unknown event_id returns an error JSON object without raising exceptions.

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?

The description is front-loaded with the tool's purpose, then moves efficiently through usage constraints, exclusions, alternatives, and error behavior. There is no filler or repetition that detracts from the key guidance.

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?

For a single-parameter read-only lookup with no output schema, the description is complete enough: it covers what data is returned, how to obtain a valid event_id, when not to use the tool, and how errors are surfaced. Nothing essential for correct invocation 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 description coverage is 100%, so the event_id type and examples are already documented. The description adds meaningful semantics by requiring a valid event_id obtained from the sibling tools and by clarifying the active-pool constraint and error behavior for invalid IDs.

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 uses a specific verb, 'Retrieve,' and names the exact resource, a disaster by event_id. It also distinguishes the tool from both siblings by naming list_active_disasters and find_disasters_near_coordinates as alternatives for browsing and proximity queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use the tool: only when the caller already holds a valid event_id from list_active_disasters or find_disasters_near_coordinates. It also gives clear when-not-to-use cases for browsing and coordinate proximity queries, naming the correct sibling in each case.

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

list_active_disastersA
Read-onlyIdempotent

List and filter real-time global natural disasters from the active 24-48 hour monitoring pool. Use to discover ongoing hazards, search by nation, or filter by hazard type or severity level. Do not use if you already possess a specific event_id (use get_disaster_by_id instead) or to evaluate coordinate proximity (use find_disasters_near_coordinates instead). Pure read-only operation with zero side effects. Returns {'matched_count': 0, 'events': []} when no incidents match filter criteria without raising errors.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of disaster records to return in payload (integer between 1 and 50, defaults to 10).
countryNoCase-insensitive country name substring (e.g., 'Japan', 'Philippines', 'United States'). Default is null (worldwide).
severityNoAlert severity level. Allowed values: 'minor', 'moderate', 'severe', 'catastrophic'. Default is null (all severities).
event_typeNoNatural hazard category. Allowed values: 'earthquake', 'tsunami', 'flood', 'cyclone', 'wildfire', 'volcanic_eruption', 'severe_weather'. Default is null (all types).

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the 'pure read-only, zero side effects' line is largely redundant. However, it adds genuinely new behavior beyond the annotations: the empty-result contract ({'matched_count': 0, 'events': []} with no raised error) and the temporal scope of the monitoring pool.

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?

Three sentences, front-loaded with purpose then routing then return behavior; each earns its place. The 'pure read-only operation with zero side effects' clause is the only mild redundancy given the annotations already state it.

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?

No output schema exists, and the description partially compensates by describing the empty-match return shape, which is the highest-risk return case for an agent. It does not describe the populated event object's fields, but that is a minor gap for a filtered-list read tool.

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 all four parameters (including the enums for severity and event_type) are already fully documented in the schema. The description's mention of nation, hazard type, and severity maps to those params but adds no format or semantics beyond them, making the baseline 3 appropriate.

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 (list/filter), resource (real-time global natural disasters), and scope (active 24-48 hour monitoring pool). It explicitly names both siblings it is not and the conditions that select them, so an agent can distinguish it 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use ('discover ongoing hazards, search by nation, or filter by hazard type or severity') plus two when-not-to-use cases with named alternatives (get_disaster_by_id for a known event_id, find_disasters_near_coordinates for proximity). Routing is unambiguous.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.4
    • Changedfind_disasters_near_coordinates15 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / latitude / description
        Added value: +"Target latitude in decimal degrees (-90.0 to 90.0, WGS-84 standard)."
      • addedInput schema / properties / latitude / maximum
        Added value: +90
      • addedInput schema / properties / latitude / minimum
        Added value: +-90
      • removedInput schema / properties / latitude / title
        Removed value: -"Latitude"
      • addedInput schema / properties / longitude / description
        Added value: +"Target longitude in decimal degrees (-180.0 to 180.0, WGS-84 standard)."
      • addedInput schema / properties / longitude / maximum
        Added value: +180
      • addedInput schema / properties / longitude / minimum
        Added value: +-180
      • removedInput schema / properties / longitude / title
        Removed value: -"Longitude"
      • addedInput schema / properties / radius_km / description
        Added value: +"Radial search perimeter measured in kilometers (km) from target coordinates (1.0 to 5000.0, defaults to 500.0 km)."
      • addedInput schema / properties / radius_km / maximum
        Added value: +5000
      • addedInput schema / properties / radius_km / minimum
        Added value: +1
      • removedInput schema / properties / radius_km / title
        Removed value: -"Radius Km"
      • removedInput schema / title
        Removed value: -"find_disasters_near_coordinatesArguments"
      • changedOutput schema / (root)
        Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "find_disasters_near_coordinatesOutput",
-  "type": "object"
-}New value: +null
    • Changedget_disaster_by_id5 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / event_id / description
        Added value: +"Unique incident identifier string (e.g., 'usgs_nc75001234', 'gdacs_1002341', or 'news_e5f6g7h8')."
      • removedInput schema / properties / event_id / title
        Removed value: -"Event Id"
      • removedInput schema / title
        Removed value: -"get_disaster_by_idArguments"
      • changedOutput schema / (root)
        Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "get_disaster_by_idOutput",
-  "type": "object"
-}New value: +null
    • Changedlist_active_disasters24 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • removedInput schema / properties / country / anyOf
        Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
      • removedInput schema / properties / country / default
        Removed value: -null
      • addedInput schema / properties / country / description
        Added value: +"Case-insensitive country name substring (e.g., 'Japan', 'Philippines', 'United States'). Default is null (worldwide)."
      • removedInput schema / properties / country / title
        Removed value: -"Country"
      • addedInput schema / properties / country / type
        Added value: +"string"
      • removedInput schema / properties / event_type / anyOf
        Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
      • removedInput schema / properties / event_type / default
        Removed value: -null
      • addedInput schema / properties / event_type / description
        Added value: +"Natural hazard category. Allowed values: 'earthquake', 'tsunami', 'flood', 'cyclone', 'wildfire', 'volcanic_eruption', 'severe_weather'. Default is null (all types)."
      • addedInput schema / properties / event_type / enum
        Added value: +[
+  "earthquake",
+  "tsunami",
+  "flood",
+  "cyclone",
+  "wildfire",
+  "volcanic_eruption",
+  "severe_weather"
+]
      • removedInput schema / properties / event_type / title
        Removed value: -"Event Type"
      • addedInput schema / properties / event_type / type
        Added value: +"string"
      • addedInput schema / properties / limit / description
        Added value: +"Maximum number of disaster records to return in payload (integer between 1 and 50, defaults to 10)."
      • addedInput schema / properties / limit / maximum
        Added value: +50
      • addedInput schema / properties / limit / minimum
        Added value: +1
      • removedInput schema / properties / limit / title
        Removed value: -"Limit"
      • removedInput schema / properties / severity / anyOf
        Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
      • removedInput schema / properties / severity / default
        Removed value: -null
      • addedInput schema / properties / severity / description
        Added value: +"Alert severity level. Allowed values: 'minor', 'moderate', 'severe', 'catastrophic'. Default is null (all severities)."
      • addedInput schema / properties / severity / enum
        Added value: +[
+  "minor",
+  "moderate",
+  "severe",
+  "catastrophic"
+]
      • removedInput schema / properties / severity / title
        Removed value: -"Severity"
      • addedInput schema / properties / severity / type
        Added value: +"string"
      • removedInput schema / title
        Removed value: -"list_active_disastersArguments"
      • changedOutput schema / (root)
        Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "list_active_disastersOutput",
-  "type": "object"
-}New value: +null
  2. 3 tool updatesv0.1.0
    • First observedfind_disasters_near_coordinates
    • First observedget_disaster_by_id
    • First observedlist_active_disasters
Deploy Server
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

TDQS

A4.5/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a distinct purpose: discovery/filtering (list_active_disasters), single-event detail lookup (get_disaster_by_id), and spatial proximity search (find_disasters_near_coordinates). Descriptions explicitly guide when to use each and when not to, preventing misselection.

Naming Consistency5/5

All tool names use snake_case with a leading verb and clear resource description, following a consistent verb_noun pattern. The slight variation in prepositional phrases (by_id, near_coordinates) remains predictable and readable.

Tool Count4/5

Three tools is on the low end but well matched to the narrow read-only active-disaster monitoring scope. Each tool is necessary and non-redundant, though the surface could arguably host a few more query variants without bloat.

Completeness5/5

The tools cover the full read-only lifecycle for active disaster monitoring: discovery with filtering, detailed telemetry retrieval by ID, and geospatial exposure queries. No write operations are needed for this stated purpose, and minor extras like pagination or bulk retrieval are not essential.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers