@pipeworx/reliefweb

Connect: https://gateway.pipeworx.io/reliefweb/mcp · Install: one-click buttons

No MCP client? Skip the connection: POST https://gateway.pipeworx.io/v1/tools/search_packs {"query":"..."} to find a tool below, GET /v1/tools/<name> for its schema, POST the same URL with arguments for the data — see For AI agents.

Tools: 3

UN OCHA’s humanitarian information service — situation reports, needs assessments, appeals and analyses from ~4,000 humanitarian organisations, plus the curated disaster register with GLIDE numbers.

Tools

• reliefweb_reports(query?, country?, disaster_type?, source?, theme?, format?, from_date?, to_date?, include_body?, limit?, offset?)
• reliefweb_disasters(query?, country?, status?, disaster_type?, include_description?, limit?, offset?)
• reliefweb_report(report_id, max_body_chars?) — one report in full.

Auth

BYO only, and the credential is not shaped like a key.

The API is free and charges nothing. What it requires, since 1 November 2025, is a pre-approved appname query parameter on every call. An arbitrary string is refused with 403 AccessDeniedHttpException. Verified live 2026-09-17: appname=pipeworx, appname=reliefweb, appname=test all 403 on v2; v1 additionally answers 410 (decommissioned).

Request one at https://apidoc.reliefweb.int/parameters#appname. ReliefWeb reviews the request and emails the approved string, which must combine your organisation name, your purpose and random characters. Pass it as _apiKey.

Pipeworx holds no approved appname. When one arrives it is PLATFORM_RELIEFWEB_APPNAME; add platformKeyEnv to the pack manifest in the same change that lands the value, never before — declaring it first routes humanitarian questions to a tool that can only refuse.

ReliefWeb rate-limits by appname, so a shared one is a shared bucket.

Data sources

• POST https://api.reliefweb.int/v2/reports?appname=…
• POST https://api.reliefweb.int/v2/disasters?appname=…
• Field tables: https://apidoc.reliefweb.int/fields-tables

Things worth knowing:

• v1 is gone. It answers 410 telling you to use v2. Anything written against api.reliefweb.int/v1 is dead.
• The public site’s RSS feeds are not a workaround: reliefweb.int/updates/rss.xml answers 202 with a zero-byte body from server egress, browser UA or not.
• Filters take one {field, value} or an {operator, conditions[]} group — a bare array of filters is rejected.
• Date filters go on date.original (publication) as {from, to} with full ISO timestamps, not bare dates.
• Taxonomy fields (source, country, theme, format, disaster_type) come back as arrays of objects; the pack flattens them to names.
• Report bodies are long. reliefweb_reports omits them unless you ask; reliefweb_report is the one that returns full text.

Verified

2026-09-17 — refusal paths only, by design. Both the no-key refusal and the upstream 403-on-unapproved-appname path were exercised live and both say “requires an API key”. Query paths cannot be verified until an appname is approved.

Tools

• reliefweb_reports — Humanitarian situation reports, needs assessments, appeals, analyses and press releases published on ReliefWeb by ~4,000 UN agencies, NGOs, governments and research bodies. AUTHORITATIVE for “what do
• reliefweb_disasters — The ReliefWeb disaster register — UN OCHA’s curated list of humanitarian emergencies, each with a GLIDE number, disaster type, affected countries, event date and whether it is ongoing, alert or past.
• reliefweb_report — One ReliefWeb report in full — the complete body text, every attached file, the publishing organisations, the countries and disasters it covers, its theme and format, and its publication and revision