Skip to main content
Glama

reliefweb-mcp-server

by io.github.cyanheads

Search ReliefWeb Disasters

reliefweb_search_disasters
Read-onlyIdempotent

Search active and historical disasters on ReliefWeb by type, country, status, date range, and GLIDE number. Default preset covers alert, ongoing, and past disasters. Use include_archived=true to reach alert-archive entries as well, for historical research. Returns IDs suitable for use with reliefweb_get_disaster and as disaster_id filter in reliefweb_search_reports.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoSort order. Use date.created:desc for newest first (default), date.created:asc for oldest, score:desc for relevance.
textNoFull-text search query. Matches against disaster name and description.
glideNoGLIDE number (global disaster identifier, e.g., EQ-2023-000053-TUR). Use for cross-system disaster correlation.
limitNoNumber of results to return (1–1000, default 10). Each call counts against the 1,000-calls/day quota.
offsetNoZero-based offset for pagination. Use with limit and the totalCount enrichment field to page through results.
statusNoDisaster status filter. One of: alert (newly declared), ongoing, past (resolved), alert-archive. Separate multiple values with commas; case, spacing, and punctuation are ignored, and any other value is rejected with the valid list. alert-archive is only reachable with include_archived=true — asking for it without that returns nothing.
countryNoISO 3166-1 alpha-3 country code (e.g., SYR, AFG, UKR). Filters to disasters tagged with this country.
date_toNoLatest disaster creation date. Pair with date_from for a date range. A bare calendar date resolves to end of that day in UTC, so the range covers it in full; a datetime carrying any offset is resolved to UTC.
date_fromNoEarliest disaster creation date. Filters on date.created. A bare calendar date such as 2024-01-15 is accepted and resolves to start of that day in UTC; a datetime carrying any offset is resolved to UTC.
disaster_typeNoDisaster type name (e.g., Earthquake, Flood, Drought, Cyclone). Filters on type.name.
include_archivedNoInclude alert-archive disasters in results, alongside alert, ongoing, and past. Uses preset=analysis. Off by default.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
itemsNoMatching disasters.
noticeNoPresent only when the page is empty. Names the match count and the last reachable offset when the query matched records; otherwise echoes the filters applied and suggests how to broaden.
totalCountNoTotal disasters matching the query before pagination.
appliedFiltersNoThe resolved filter set the query actually ran with, after normalization and defaults. Echoes back so the agent can confirm how its inputs were interpreted.

TDQS

A4.5/5.0
Behavior5/5

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

Adds significant detail beyond annotations: default preset behavior, archived reachability, quota limit per call (1,000/day), status value validation, and date resolution semantics. The readOnlyHint and idempotentHint are already present, and the description complements them with operational behavior like pagination via totalCount enrichment field.

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 sentences, front-loaded with purpose, followed by a critical filtering nuance and a chaining hint. Every sentence earns its place with no redundancy or filler.

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 the 11-parameter complexity, an output schema for results, and read-only/idempotent annotations, the description covers all essential aspects: defaults, archived behavior, quota, date handling, and downstream usage. An agent has sufficient information to invoke correctly without additional lookups.

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's meaning is already documented thoroughly in the schema. The tool description repeats the overall filter categories but does not add new semantic detail beyond what the schema provides. Baseline of 3 is 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?

The description clearly states specific verb ('search'), resource ('disasters on ReliefWeb'), and the filter criteria (type, country, status, date range, GLIDE number). It differentiates from sibling tools by mentioning returned IDs suitable for reliefweb_get_disaster and as disaster_id filter in reliefweb_search_reports, establishing its role in a workflow.

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 clear guidance on when to use include_archived=true for historical research and default preset coverage. Names related siblings for chaining. However, it does not explicitly state when to prefer this search over reliefweb_get_disaster for single-record retrieval, leaving some inference to the agent.

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

All reliefweb-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool targets a distinct resource type (country, disaster, job, report, training, source) and a clear action (get, list, search). The search/get pairs are clearly separated by resource, with no overlapping purposes.

Naming Consistency5/5

All tools follow the consistent pattern reliefweb_<verb>_<noun>, using get, list, and search as verbs. The only minor variation is list_countries vs list_sources, but the plural nouns are appropriate for list operations.

Tool Count5/5

11 tools is well within the ideal range and covers five content types plus country and source lookups. Each tool serves a distinct function, making the set comprehensive without being bloated.

Completeness5/5

The surface provides both search and fetch operations for all primary resources (disasters, jobs, reports, training) and complete country/source lookup coverage. No obvious gaps for a read-only humanitarian data API.

Resources