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.5/5 across 9 of 9 tools scored.
Each tool targets a unique resource-action combination: country, disaster, report, source, job, training, with distinct get/list/search verbs. No two tools have overlapping purposes.
All tools follow a consistent reliefweb_verb_noun snake_case pattern (e.g., reliefweb_get_country, reliefweb_search_reports). No mixing of conventions.
With 9 tools, the set covers the key operations for a humanitarian data API: listing, searching, and retrieving full details for core entities. The scope feels well-calibrated.
The set includes get tools for countries, disasters, and reports, but missing get tools for jobs and training, which may require full details after search. This gap could hinder agents needing complete information.
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 totalCount 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. |
| 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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds value by specifying the output includes ISO3 codes and status, and that crisis_only filters to active situations. However, it does not elaborate on pagination behavior beyond the schema-defined parameters, which is a minor gap.
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 extremely concise—two sentences that front-load the core purpose and immediately provide actionable guidance. Every sentence adds value without redundancy or unnecessary detail.
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 that an output schema exists (not shown but indicated by context), the description appropriately focuses on what the tool does and how to use its output (ISO3 codes and status). It covers filtering and next-step guidance, making the tool definition complete for an AI agent.
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?
The input schema covers all three parameters with descriptions, achieving 100% coverage. The description mentions crisis_only and its effect, but this is also present in the schema. Thus, the description adds no significant new meaning beyond what the schema already provides, warranting a baseline score of 3.
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 lists all countries and territories tracked by ReliefWeb, optionally filtered by active humanitarian situations. It distinguishes itself from siblings by explicitly mentioning using the ISO3 code with reliefweb_get_country for full profiles.
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 explicit guidance on when to use this tool versus alternatives: it directs users to reliefweb_get_country for a full profile by ISO3 code and explains how to filter for active crises using crisis_only=true. This effectively tells the AI agent when to choose this tool over siblings.
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 (e.g., Government, International Organization, NGO, Academia). 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 totalCount to page through results. |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | Source organizations contributing content to ReliefWeb. |
| 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 behavioral context: returns specific fields (short names, types, URLs) and mentions per-call quota impact in parameter description. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and filters, followed by usage guidance. Every sentence adds value, 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 the presence of an output schema (not shown but indicated), the description adequately covers purpose, parameters, and integration context. Annotations provide safety hints. No gaps evident.
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% and each parameter has a clear description. The description adds no new semantic information beyond the schema, meeting the baseline for high-coverage tools.
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 specific verb 'Browse', identifies resource 'source organizations', and mentions optional filters (name text, type). It clearly distinguishes from sibling tools that operate 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 how to use the output (shortname) with other search tools (reliefweb_search_reports, etc.), providing clear context for integration. Lacks explicit when-not-to-use guidance, but the positive guidance is strong.
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 totalCount 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. |
| message | No | Recovery hint when results are empty — echoes filters applied and suggests how to broaden. |
| totalCount | Yes | Total disasters matching the query before pagination. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, idempotentHint) are complemented by description noting returned IDs usable with other tools, default preset, and archival behavior—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?
Two concise sentences: first states purpose and key filters, second adds archival guidance and cross-tool utility. 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 11 parameters fully described in schema, output schema present, and annotations covering safety/idempotency, the description sufficiently covers defaults, archival usage, and tool integration.
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 has 100% coverage, and description adds value by explaining default preset, quota impact for limit, and archival preset behavior—beyond 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?
Description clearly states it searches active and historical disasters by specific filters (type, country, status, date range, GLIDE), distinguishing it from sibling tools that focus on single resources or different topics.
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 coverage and explicit guidance for including archived disasters via include_archived=true. No explicit alternatives or when-not-to-use, but sufficient 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_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 totalCount 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. |
| message | No | Recovery hint when results are empty — echoes filters applied and suggests how to broaden. |
| totalCount | Yes | Total jobs matching the query before pagination. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral context that archived or expired jobs are excluded by default, which is not stated in annotations. This enhances transparency. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each carrying distinct and essential information: purpose with filters, default behavior (exclude archived), and a usage tip for text search. It is front-loaded with the main action and very concise, with no unnecessary 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 8 parameters (none required) and an output schema, the description adequately covers the main purpose, filters, and a key behavioral note. It could mention pagination (limit/offset) or the full scope of parameters, but the schema and output schema compensate. The description is sufficient for an agent to use the tool effectively.
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 parameters are well-documented. The description adds semantic value by mapping filters like 'by country, organization, career category, theme, and experience level' to corresponding parameters and providing a usage hint for the 'text' parameter ('Use text search for role titles and job descriptions.'). This goes 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 searches for humanitarian job listings on ReliefWeb with specific filters (country, organization, career category, theme, experience level). The verb 'search' and resource 'jobs' are explicit, and the tool name itself distinguishes it from siblings like reliefweb_search_disasters or 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 provides context on when to use this tool: it returns current open positions by default, excluding archived/expired jobs. It also suggests using text search for role titles and job descriptions. However, it does not explicitly contrast with sibling tools or state when not to use it, which would be beneficial.
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 totalCount from the response 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). |
| message | 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. |
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 valuable context: the quota of 1,000 calls/day, that report body is excluded due to size (10–100KB each), and the effect of include_archived. This additional behavioral information goes beyond annotations 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 approximately 5 sentences, structured with purpose first, then guidance, then behavioral notes. Every sentence adds value, and there is no redundant or filler text. It is concise yet comprehensive.
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 complexity (14 parameters, nested objects, output schema), the description is complete. It covers filtering, pagination (offset/limit), quota, archive inclusion, and the reason body is excluded. The existence of an output schema reduces the need to explain return values. All essential aspects are addressed.
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?
With 100% schema coverage, baseline is 3. The description significantly adds meaning: sort includes examples (date.original:desc, score:desc), limit notes the quota impact, date_from/date_to provide ISO 8601 examples, filter explains use of raw filter object, include_archived mentions preset=analysis, and disaster_id links to another tool. This exceeds baseline expectations.
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 with filtering by multiple criteria. It distinguishes itself from siblings by explicitly mentioning the use of reliefweb_get_report for full body text, which clarifies the scope.
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 guidance on when to use this tool (search with filtering) and when to use a sibling tool (get_report for full content). It also suggests using include_archived for historical research. However, it does not explicitly contrast with other search tools like reliefweb_search_disasters for disaster-specific searches.
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 totalCount 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. |
| message | 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds context about the quota ('Each call counts against the 1,000-calls/day quota') and the distinct date fields, which go beyond the 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?
The description is compact at 4 sentences, front-loading the core purpose and filter scope. Every sentence serves a distinct function: purpose, coverage, date warning, usage tip. 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 10 parameters, no required fields, 100% schema coverage, and no output schema, the description covers the search scope, key filters, and date handling. It doesn't detail pagination beyond parameter descriptions, but it is largely complete for a search tool.
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%, but the description enriches parameters by explaining the date field usage pattern and giving examples of format and career_category values (e.g., 'Workshop, E-learning, Conference, Seminar'), adding meaning 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 'Search humanitarian training and learning opportunities on ReliefWeb by country, format, date, source, career category, and language.' It specifies the resource (training) and action (search), and distinguishes from sibling tools like 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?
Explicit guidance is given on the date field difference: '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.' While it doesn't explicitly state when not to use, the sibling list and description imply this is for training only.
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!