Skip to main content
Glama

reliefweb-mcp-server

by io.github.cyanheads

Search ReliefWeb Reports

reliefweb_search_reports
Read-onlyIdempotent

Search humanitarian reports on ReliefWeb with filtering by country, disaster, format, theme, language, source, and date. Returns paginated summaries — use reliefweb_get_report to fetch full body text. Report body is excluded from results (10–100KB each); call get_report when document content is needed. Every report is reachable by default — reports have no archived class, so include_archived has no effect here. Note: each call counts against the 1,000 calls/day quota.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoSort order. Use date.original:desc for newest first (default), date.original:asc for oldest first, score:desc for relevance.
textNoFull-text search query. Matches against title, body, and key metadata fields. Use plain natural language or keywords.
limitNoNumber of results to return (1–1000, default 10). Use a smaller value for targeted lookups; larger for bulk research. Each call counts against the 1,000-calls/day quota.
themeNoSector or cross-cutting theme (e.g., Health, Food and Nutrition, Shelter and Non-Food Items, Protection). Open-ended — matches theme.name exactly as ReliefWeb spells it.
filterNoRaw ReliefWeb filter object for compound conditions not covered by named params. Example: {"operator": "AND", "conditions": [{"field": "format.name", "value": "Map"}, {"field": "language.code", "value": "fr"}]}.
formatNoContent format filter. One of: News and Press Release, Situation Report, Map, Infographic, Analysis, Other, Assessment, Manual and Guideline, Appeal, UN Document, Evaluation and Lessons Learned. Case, spacing, and punctuation are ignored; any other value is rejected with the valid list.
offsetNoZero-based offset for pagination. Use with limit and the totalCount enrichment field to page through large result sets.
sourceNoOrganization short name (e.g., UNHCR, OCHA, WFP). Filters on source.shortname.
countryNoISO 3166-1 alpha-3 country code (e.g., SYR, AFG, UKR). Filters to content tagged with this country.
date_toNoLatest publication 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.
languageNoISO 639-1 language code (e.g., en, fr, es, ar). Filters on language.code.
date_fromNoEarliest publication date. Filters on date.original (source publication date). 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_idNoReliefWeb numeric disaster ID. Filters to reports linked to a specific disaster. Get the ID from reliefweb_search_disasters.
include_archivedNoNo effect on reports. Reports have no archived class — every report is already in scope, whatever this is set to. Kept so existing calls that pass it keep working; it is meaningful on reliefweb_search_jobs, reliefweb_search_training, and reliefweb_search_disasters.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
itemsNoMatching reports (summaries only — use reliefweb_get_report for full body).
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 reports 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.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it notes that report bodies are excluded from results (with size estimates), that include_archived has no effect on reports, and that each call counts against a 1,000/day quota. This gives the agent important operational constraints not evident from annotations.

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?

The description is concise given the tool's complexity (14 parameters, many with nuanced behavior). It front-loads the core purpose and quickly notes the key limitation (no body text, use get_report). Every sentence serves a purpose—mentioning pagination, quota, and include_archived behavior. It's structured logically but could be slightly tightened to avoid repeating 'each call counts' twice, though that repetition reinforces an important constraint.

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?

This is a complex tool with 14 parameters, nested objects, and an output schema. The description covers the essential operational details: what the tool returns (paginated summaries without body text), when to use the sibling get_report, the archiving caveat, the quota impact, and how to page. The output schema likely describes the response structure, so the description doesn't need to enumerate return fields. It's complete for an agent to correctly invoke it.

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% and every parameter has a description. The description adds modest extra value beyond the schema—for instance, it explains that the text parameter matches against title, body, and metadata, and it clarifies the behavior of date_from/date_to with timezone resolution. However, most parameter details are already in the schema, so the baseline of 3 is appropriate; the description doesn't significantly elevate parameter understanding beyond what's in 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 clearly states the tool searches humanitarian reports with specific filters (country, disaster, format, theme, language, source, date) and returns paginated summaries. It distinguishes itself from sibling tools by explicitly mentioning reliefweb_get_report for full body text, which separates search from retrieval.

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 solid guidance on when to use this tool versus reliefweb_get_report (when full body is needed) and explains that include_archived has no effect on reports, directing users to sibling tools where it is meaningful. However, it doesn't explicitly state when to prefer this over reliefweb_search_disasters or other search tools, though the 'search reports' focus implicitly covers it.

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