reliefweb-mcp-server
Server Details
Search ReliefWeb humanitarian reports, disasters, jobs, training, and country profiles via MCP.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/reliefweb-mcp-server
- GitHub Stars
- 1
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 9 of 9 tools scored.
Each tool targets a distinct resource and action (get/list/search), and there is no overlap. For example, reliefweb_get_country retrieves a single country, reliefweb_list_countries lists all, and reliefweb_search_reports finds reports with filtering.
All tools follow a consistent reliefweb_verb_noun pattern in snake_case, using only get, list, and search as verbs. No mixing of conventions.
With 9 tools covering countries, disasters, reports, jobs, training, and sources, the scope is well-balanced—not too sparse or overloaded.
The set provides full read coverage: listing and fetching individual resources for each main entity, plus search capabilities. Missing write operations are appropriate for a read-only data source.
Available Tools
9 toolsreliefweb_get_countryGet ReliefWeb Country ProfileARead-onlyIdempotentInspect
Fetch a country profile from ReliefWeb by ISO3 code, including overview, humanitarian situation summary, key content links, active appeals and response plans, and useful external links. Country profiles are curated by OCHA editors and provide the authoritative situation summary for humanitarian responders.
| Name | Required | Description | Default |
|---|---|---|---|
| iso3 | Yes | ISO 3166-1 alpha-3 country code (e.g., SYR, AFG, UKR). Used to look up the country's ReliefWeb profile. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | ReliefWeb numeric country ID. |
| iso3 | No | ISO 3166-1 alpha-3 code. |
| name | Yes | Country name. |
| status | No | Humanitarian situation status. |
| urlAlias | No | Canonical ReliefWeb URL for this country page. |
| keyContent | No | Curated key content links maintained by ReliefWeb editors. |
| usefulLinks | No | Useful external links curated by ReliefWeb editors. |
| profileOverview | No | Situation overview text from the ReliefWeb editorial team. |
| appealsResponsePlans | No | Active humanitarian appeals and response plans for this country. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by noting that profiles are curated by OCHA editors and provide authoritative summaries, which is useful context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences with no wasted words. It front-loads the action and required input, then adds context about the content and curation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no enums, output schema present), the description is complete. It covers the purpose, input, content, and authority of the data, leaving no obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter iso3, and the description restates that it uses an ISO3 code. No additional semantics beyond the schema are provided, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and identifies the resource ('country profile from ReliefWeb by ISO3 code'), listing contents such as overview, humanitarian summary, and links. It clearly distinguishes from siblings like reliefweb_list_countries (which lists all countries) and other get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a specific country's profile but does not explicitly state when to use this tool over alternatives or exclude other use cases. It lacks guidance on when not to use it or mention of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reliefweb_get_disasterGet ReliefWeb DisasterARead-onlyIdempotentInspect
Fetch a disaster record by ReliefWeb numeric ID including description, affected countries, GLIDE number, profile overview, key content links, and active appeals or response plans. Use after reliefweb_search_disasters to retrieve full details.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ReliefWeb numeric disaster ID. Obtained from reliefweb_search_disasters results. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | ReliefWeb numeric disaster ID. |
| name | Yes | Disaster name. |
| glide | No | GLIDE number for cross-system correlation. |
| types | No | Disaster type names. |
| status | No | Disaster status (alert, current, past, archive). |
| urlAlias | No | Canonical ReliefWeb URL for this disaster. |
| countries | No | All countries tagged on this disaster. |
| dateEvent | No | Event date (ISO 8601), when available. |
| keyContent | No | Curated key content links from the ReliefWeb editorial team. |
| dateCreated | No | ReliefWeb index date (ISO 8601). |
| description | No | Full disaster description text. |
| primaryType | No | Primary disaster type. |
| usefulLinks | No | Useful external links curated by ReliefWeb editors. |
| primaryCountry | No | Primary affected country. |
| profileOverview | No | Profile overview text from the ReliefWeb editorial team. |
| appealsResponsePlans | No | Active appeals and response plans linked to this disaster. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. Description adds value by detailing the specific fields returned (e.g., active appeals), exceeding what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first defines purpose, second provides usage guidance. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present), the description is complete. It covers all key aspects: what is fetched, what it includes, and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter. Description adds context on where to obtain the ID ('from reliefweb_search_disasters results'), enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Fetch a disaster record by ReliefWeb numeric ID' and lists what it includes. It distinguishes itself from sibling tools like reliefweb_search_disasters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use after reliefweb_search_disasters, providing clear usage context. Does not mention when not to use, but is sufficient for a simple retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reliefweb_get_reportGet ReliefWeb ReportARead-onlyIdempotentInspect
Fetch a single ReliefWeb report by its numeric ID with full body text, file attachments, and all metadata. Use after reliefweb_search_reports to retrieve document content — body is excluded from search results to manage context budget. Report bodies can be 10–100KB; call this only when you need the full document text.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ReliefWeb numeric report ID. Obtained from reliefweb_search_reports results. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | ReliefWeb numeric report ID. |
| body | No | Full report body text (HTML). Present for most reports; absent for binary-only documents. |
| title | Yes | Report title. |
| themes | No | Humanitarian theme/sector names. |
| formats | No | Content format names. |
| sources | No | Publishing organizations (short names). |
| fileUrls | No | Direct file download URLs attached to this report. |
| urlAlias | No | Canonical ReliefWeb URL for this report. |
| countries | No | All countries tagged on this report. |
| languages | No | Language codes (ISO 639-1). |
| dateCreated | No | ReliefWeb index date (ISO 8601). |
| dateOriginal | No | Source publication date (ISO 8601). |
| primaryCountry | No | Primary country name for this report. |
| headlineSummary | No | Short editorial summary from the headline block, when present. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds value by disclosing that report bodies can be large (10-100KB) and that body text is excluded from search results, which is useful for context management.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with no wasted words. Front-loaded with the action and scope, then immediately provides usage guidance. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present, clear annotations), the description covers purpose, usage context, size considerations, and relationship to sibling tools. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'id' described as 'ReliefWeb numeric report ID. Obtained from reliefweb_search_reports results.' The description reinforces that the ID is numeric and where to get it, adding context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a single ReliefWeb report by its numeric ID with full body text, file attachments, and all metadata.' It specifies the verb (fetch), resource (single ReliefWeb report), and scope (full content). It also distinguishes from siblings by mentioning use after reliefweb_search_reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use ('Use after reliefweb_search_reports to retrieve document content'), why ('body is excluded from search results to manage context budget'), and provides sizing guidance ('Report bodies can be 10–100KB; call this only when you need the full document text').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reliefweb_list_countriesList ReliefWeb CountriesARead-onlyIdempotentInspect
List all countries and territories tracked by ReliefWeb, optionally filtered to active humanitarian situations. Returns ISO3 codes and status for each entry — use the ISO3 code with reliefweb_get_country to fetch a full profile. Set crisis_only=true to limit results to countries with active humanitarian situations.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return (1–1000, default 100). Each call counts against the 1,000-calls/day quota. | |
| offset | No | Zero-based offset for pagination. Use with limit and the totalCount enrichment field to page through results. | |
| crisis_only | No | When true, filters to countries with an active humanitarian situation (status alert or current). Default false returns all countries. |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | Countries tracked by ReliefWeb. |
| notice | No | Recovery hint when results are empty — echoes the active filter and suggests how to broaden. Absent on successful result pages. |
| totalCount | Yes | Total countries matching the filter before pagination. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by specifying the return format (ISO3 codes and status) and the effect of the crisis_only filter. Annotations already indicate read-only, idempotent, and open-world behavior, so the description complements them without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main purpose, and contains no wasted words. It efficiently conveys the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the straightforward nature of the tool, the description covers all necessary aspects: what the tool does, filtering option, and linkage to a related tool. No important details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds extra context for the limit parameter (mentioning the daily quota) and reinforces the crisis_only filter behavior. This provides useful information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all countries/territories tracked by ReliefWeb with optional filtering, and distinguishes from sibling tool reliefweb_get_country by mentioning the ISO3 code can be used to fetch a full profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use (listing countries, optionally filtered) and directs the user to reliefweb_get_country for full profiles. It does not explicitly state when not to use it but gives sufficient guidance for typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reliefweb_list_sourcesList ReliefWeb SourcesARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Full-text search query. Matches against organization name and short name. | |
| type | No | Organization type. Must match exact API values: "Government", "International Organization", "Non-governmental Organization", "Academia", "United Nations", "Other". Filters on type.name. | |
| limit | No | Number of results to return (1–1000, default 10). Each call counts against the 1,000-calls/day quota. | |
| offset | No | Zero-based offset for pagination. Use with limit and the totalCount enrichment field to page through results. |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | Source organizations contributing content to ReliefWeb. |
| notice | No | Recovery hint when results are empty — echoes the active filters and suggests how to broaden. Absent on successful result pages. |
| totalCount | Yes | Total sources matching the query before pagination. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds return fields but does not disclose additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With good annotations and full schema coverage, the description adequately covers the tool's purpose and output usage. Could mention pagination briefly but schema already handles it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description repeats that filters are optional but adds no new meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's for browsing source organizations contributing to ReliefWeb, with optional filters by text or type. It distinguishes from sibling tools that focus on countries, disasters, reports, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool and how to use the results (shortname value as filter in other search tools). Lacks explicit exclusion scenarios but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reliefweb_search_disastersSearch ReliefWeb DisastersARead-onlyIdempotentInspect
Search active and historical disasters on ReliefWeb by type, country, status, date range, and GLIDE number. Default preset covers alert, current, and past disasters. Use include_archived=true to include alert-archive and archive entries for historical research. Returns IDs suitable for use with reliefweb_get_disaster and as disaster_id filter in reliefweb_search_reports.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order. Use date.created:desc for newest first (default), date.created:asc for oldest, score:desc for relevance. | |
| text | No | Full-text search query. Matches against disaster name and description. | |
| glide | No | GLIDE number (global disaster identifier, e.g., EQ-2023-000053-TUR). Use for cross-system disaster correlation. | |
| limit | No | Number of results to return (1–1000, default 10). Each call counts against the 1,000-calls/day quota. | |
| offset | No | Zero-based offset for pagination. Use with limit and the totalCount enrichment field to page through results. | |
| status | No | Disaster status filter. Values: alert (newly declared), current (ongoing), past (resolved), alert-archive, archive. Separate multiple values with commas. Default preset includes alert, current, past. | |
| country | No | ISO 3166-1 alpha-3 country code (e.g., SYR, AFG, UKR). Filters to disasters tagged with this primary country. | |
| date_to | No | Latest disaster creation date (ISO 8601). Pair with date_from for a date range. | |
| date_from | No | Earliest disaster creation date (ISO 8601). Filters on date.created. | |
| disaster_type | No | Disaster type name (e.g., Earthquake, Flood, Drought, Cyclone). Filters on type.name. | |
| include_archived | No | Include alert-archive and archive disasters in results. Uses preset=analysis. Off by default. |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | Matching disasters. |
| notice | No | Recovery hint when results are empty — echoes filters applied and suggests how to broaden. |
| totalCount | Yes | Total disasters matching the query before pagination. |
| appliedFilters | Yes | The resolved filter set the query actually ran with, after normalization and defaults. Echoes back so the agent can confirm how its inputs were interpreted. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, idempotentHint) are consistent. Description adds quota mention per call and explains that returned IDs are suitable for other tools. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single minimal paragraph, front-loaded with purpose, no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, 100% schema coverage, annotations, and output schema, the description is complete. It references pagination via totalCount and cross-links to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds minor guidance (e.g., include_archived usage) but does not compensate beyond baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Search active and historical disasters on ReliefWeb' with specific filters (type, country, status, date range, GLIDE). Distinguishes from siblings by mentioning return of IDs for reliefweb_get_disaster and as filter in reliefweb_search_reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on default preset, use of include_archived for historical research, and connection to sibling tools. Does not explicitly state when not to use, but the examples and cross-references imply appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reliefweb_search_jobsSearch ReliefWeb JobsARead-onlyIdempotentInspect
Search humanitarian job listings on ReliefWeb by country, organization, career category, theme, and experience level. Returns current open positions — archived or expired jobs are excluded by default. Use text search for role titles and job descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Full-text search query. Matches against job title, body, and key metadata fields. | |
| limit | No | Number of results to return (1–1000, default 10). Each call counts against the 1,000-calls/day quota. | |
| theme | No | Sector or cross-cutting theme (e.g., Health, Food and Nutrition, Protection). Filters on theme.name. | |
| offset | No | Zero-based offset for pagination. Use with limit and the totalCount enrichment field to page through results. | |
| source | No | Organization short name (e.g., UNHCR, OCHA, WFP). Filters on source.shortname. | |
| country | No | ISO 3166-1 alpha-3 country code (e.g., SYR, AFG, UKR). Filters to jobs tagged with this country. | |
| experience | No | Experience level (e.g., 0-2 years, 3-4 years, 5-9 years). Filters on experience.name. | |
| career_category | No | Humanitarian career track (e.g., Programme and Project Management, Information and Communications Technology, Logistics and Telecommunications). Filters on career_categories.name. |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | Matching job listings. |
| notice | No | Recovery hint when results are empty — echoes filters applied and suggests how to broaden. |
| totalCount | Yes | Total jobs matching the query before pagination. |
| appliedFilters | Yes | The resolved filter set the query actually ran with, after normalization and defaults. Echoes back so the agent can confirm how its inputs were interpreted. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. The description adds valuable behavioral details: returns only current open positions, excludes archived/expired by default, and clarifies text search scope. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded purpose, efficient delivery of behavioral info and usage hint. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high schema coverage and presence of output schema, the description covers purpose, behavior, and usage guidance sufficiently. No missing critical context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. Description adds minimal extra value by mentioning 'text search for role titles and job descriptions' and listing filter dimensions, but largely reiterates what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search humanitarian job listings on ReliefWeb' with explicit filter dimensions (country, organization, career category, theme, experience level), distinguishing it from sibling tools that search disasters, reports, or training.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description specifies it returns current open positions and excludes archived/expired by default, giving clear context for when to use. It advises using text search for role titles/job descriptions. While it doesn't explicitly list when not to use, sibling tool purposes make the distinction obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reliefweb_search_reportsSearch ReliefWeb ReportsARead-onlyIdempotentInspect
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. Use preset include_archived=true to include expired or archived reports in historical research. Note: each call counts against the 1,000 calls/day quota.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order. Use date.original:desc for newest first (default), date.original:asc for oldest first, score:desc for relevance. | |
| text | No | Full-text search query. Matches against title, body, and key metadata fields. Use plain natural language or keywords. | |
| limit | No | Number 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. | |
| theme | No | Sector or cross-cutting theme (e.g., Health, Food and Nutrition, Shelter and NFI, Protection). Matches theme.name. | |
| filter | No | Raw 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"}]}. | |
| format | No | Content format filter. Valid values: Situation Report, Assessment, Analysis, Map, Infographic, Manual and Guideline, News and Press Release, Policy Document, Appeal, Financial Report, Evaluation and Lessons Learned, Other. | |
| offset | No | Zero-based offset for pagination. Use with limit and the totalCount enrichment field to page through large result sets. | |
| source | No | Organization short name (e.g., UNHCR, OCHA, WFP). Filters on source.shortname. | |
| country | No | ISO 3166-1 alpha-3 country code (e.g., SYR, AFG, UKR). Filters to content tagged with this country. | |
| date_to | No | Latest publication date (ISO 8601). Pair with date_from for a date range. | |
| language | No | ISO 639-1 language code (e.g., en, fr, es, ar). Filters on language.code. | |
| date_from | No | Earliest publication date (ISO 8601, e.g., 2024-01-15T00:00:00+00:00). Filters on date.original (source publication date). | |
| disaster_id | No | ReliefWeb numeric disaster ID. Filters to reports linked to a specific disaster. Get the ID from reliefweb_search_disasters. | |
| include_archived | No | Include archived and to-review content in addition to published. Uses preset=analysis. Off by default. |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | Matching reports (summaries only — use reliefweb_get_report for full body). |
| notice | No | Recovery hint when results are empty — echoes the filters applied and suggests how to broaden. Absent on successful result pages. |
| totalCount | Yes | Total reports matching the query before pagination. |
| appliedFilters | Yes | The resolved filter set the query actually ran with, after normalization and defaults. Echoes back so the agent can confirm how its inputs were interpreted. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds crucial behavioral details: report body excluded, pagination, quota consumption, and filter object usage. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no fluff, but could be better structured (e.g., bullet points for filters). It is front-loaded with the main action and then details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters and existing output schema, the description covers all necessary aspects: filtering, pagination, relation to get_report, quota, and archived content. It mentions totalCount enrichment, completing the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond schema: e.g., limit explains quota, filter provides example, include_archived describes preset. This justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 on ReliefWeb with multiple filters. It distinguishes from siblings like reliefweb_get_report, which fetches full body text, and other search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use this tool vs. reliefweb_get_report for full text, and when to use include_archived for historical research. Also mentions the 1,000 calls/day quota, guiding usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reliefweb_search_trainingSearch ReliefWeb TrainingARead-onlyIdempotentInspect
Search humanitarian training and learning opportunities on ReliefWeb by country, format, date, source, career category, and language. Covers workshops, e-learning, conferences, and other capacity-building events. Training date fields use date.start / date.end — different from report date fields. Use date_start_from and date_start_to to find upcoming training within a window.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Full-text search query. Matches against training title and description. | |
| limit | No | Number of results to return (1–1000, default 10). Each call counts against the 1,000-calls/day quota. | |
| format | No | Training format (e.g., Workshop, E-learning, Conference, Seminar). Filters on format.name. | |
| offset | No | Zero-based offset for pagination. Use with limit and the totalCount enrichment field to page through results. | |
| source | No | Organization short name. Filters on source.shortname. | |
| country | No | ISO 3166-1 alpha-3 country code (e.g., KEN, ETH, COD). Filters to training tagged with this country. | |
| language | No | ISO 639-1 language code (e.g., en, fr, es). Filters on language.code. | |
| date_start_to | No | Training start date upper bound (ISO 8601). Filters on date.start — pair with date_start_from for a window. | |
| career_category | No | Humanitarian career track (e.g., Programme and Project Management, Information and Communications Technology). Filters on career_categories.name. | |
| date_start_from | No | Training start date lower bound (ISO 8601). Filters on date.start — use to find training starting after a given date. |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | Matching training opportunities. |
| notice | No | Recovery hint when results are empty — echoes filters applied and suggests how to broaden. |
| totalCount | Yes | Total training listings matching the query before pagination. |
| appliedFilters | Yes | The resolved filter set the query actually ran with, after normalization and defaults. Echoes back so the agent can confirm how its inputs were interpreted. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint. The description adds behavioral context: the limit parameter description notes a 1,000-calls/day quota, and the offset parameter mentions pagination using totalCount. These go beyond annotations, though no further details on data freshness or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a key differentiation on date fields. It is three sentences long, concise, and includes parameter descriptions in the schema. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters, a clear output schema, and robust annotations, the description covers the main functionality and important nuances (date fields, quota). It could mention pagination more explicitly, but overall it is sufficient for a search tool with good schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the date field difference (date.start vs report date fields) and usage of date_start_from/date_start_to for window queries. Parameter descriptions also add value (e.g., quota note for limit, country code format).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches humanitarian training and learning opportunities by multiple filters, and mentions coverage of workshops, e-learning, conferences. It distinguishes from sibling tools like reliefweb_search_reports by explicitly focusing on training.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description highlights that training date fields (date.start/date.end) differ from report date fields, providing one usage hint. However, it does not explicitly state when to use this tool versus alternatives like reliefweb_search_jobs or reliefweb_search_reports, nor does it provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!