Skip to main content
Glama

reliefweb-mcp-server

by io.github.cyanheads

List ReliefWeb Sources

reliefweb_list_sources
Read-onlyIdempotent

Browse source organizations that contribute content to ReliefWeb, optionally filtered by name text or organization type. Returns short names, types, and URLs. Use the shortname value with the source filter in reliefweb_search_reports, reliefweb_search_jobs, and reliefweb_search_training.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNoFull-text search query. Matches against organization name and short name.
typeNoOrganization type. One of: Non-governmental Organization, International Organization, Academic and Research Institution, Other, Government, Media, Red Cross/Red Crescent Movement. Filters on type.name.
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.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
itemsNoSource organizations contributing content to ReliefWeb.
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 sources matching the query before pagination.

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already disclose readOnlyHint, openWorldHint, and idempotentHint, so the safety and repeatability profile is covered. The description adds only that it returns short names, types, and URLs, which is minor and does not go beyond what the output schema would convey. No contradiction with 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?

The description is two sentences long, with the core purpose front-loaded and the downstream usage in the second sentence. There is no filler or redundancy; every sentence earns its place.

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 simple list tool with four optional parameters, all documented in the schema, and an output schema present, the description covers the essential context: what it lists, optional filters, returned fields, and how to use the output. It also leaves pagination details to the parameter descriptions, which is appropriate.

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 each parameter (text, type, limit, offset) is fully documented in the schema. The tool description only restates the option to filter by name text or organization type, adding no new meaning beyond the schema. This matches the baseline for full schema coverage.

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 states a specific verb ('browse') and resource ('source organizations'), and explicitly lists the returned fields (short names, types, URLs). It is clearly distinct from sibling tools like reliefweb_list_countries, which lists countries rather than sources.

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 concrete downstream guidance: use the returned shortname value with the source filter in the search tools. It does not explicitly state when to use this tool versus alternatives, but the resource type is unambiguous relative to sibling list_countries, so the usage context is clear enough.

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