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
- Server Listing
- @cyanheads/reliefweb-mcp-server
Available Tools
11 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. Each curated list also has an archive — thousands of entries deep for a long-running crisis — which the profile leaves out. Two alternative selectors, at most one per call: sections names parts of the profile to return, archive pages one list's archived entries in place of the profile. A profile over the response budget comes back as a section outline naming every section and its byte size. Nothing is truncated on any path.
| 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. | |
| archive | No | Archive mode: return a page of one curated list's ARCHIVED entries instead of the country record. The response carries the record identity, the selected list, and total / shown / offset, plus a next offset while more entries remain. Mutually exclusive with sections — sections slices the record, archive replaces it — and a call supplying both is rejected. A record over the response budget still answers an archive call with the page: a page is bounded by limit and carries none of the record prose, so it never outlines. | |
| sections | No | Sections of the country record to return, named by the sections[].name values an outline response lists. Omit for the whole record, or for a section outline when the record is over the response budget. Identity metadata — the record's ID, its name, and its canonical URL — comes back alongside whatever is requested. The call is self-contained — the record is re-fetched and sliced, so no prior call has to be repeated. This names parts of the profile itself and never reaches archived entries — use archive for those. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | ReliefWeb numeric country ID. |
| iso3 | No | ISO 3166-1 alpha-3 code. |
| kind | No | full when the record — or the sections asked for — is returned in whole; outline when the record exceeded the response budget and only its section index is returned; archive when the call asked for a page of one curated list's archived entries, which is returned in place of the record. |
| name | No | Country name. |
| error | No | Present when the call failed. Absent on success. |
| status | No | Humanitarian situation status. |
| archive | No | One page of a curated list's archived entries, returned in place of the record. |
| sections | No | Every section of the record, largest first. Pass the names back in `sections` to retrieve them. |
| urlAlias | No | Canonical ReliefWeb URL for this country page. |
| keyContent | No | Currently-active curated key content links maintained by ReliefWeb editors — the present curated set. The archived entries are reachable with archive: { list: "keyContent" }. |
| usefulLinks | No | Currently-active useful external links curated by ReliefWeb editors — the present set. The archived entries are reachable with archive: { list: "usefulLinks" }. |
| outlineNotice | No | How to re-call this tool for specific sections of the record. |
| profileOverview | No | Situation overview text from the ReliefWeb editorial team. |
| appealsResponsePlans | No | Currently-active humanitarian appeals and response plans for this country — the present set. The archived entries are reachable with archive: { list: "appealsResponsePlans" }. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, which the description does not contradict. Beyond that, it discloses important behavior: the section-outline fallback when a record exceeds the response budget, that nothing is truncated, and that archive calls always return a page regardless of budget. These details go well beyond the annotation coverage and give an agent accurate expectations for edge cases.
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 about 120 words and packs substantive information into each sentence. It opens with the core purpose, then explains the archive and sections selectors, and closes with the budget fallback. There is minor redundancy with the schema (e.g., mutual exclusivity), but overall it is efficiently structured without fluff, earning a 4 rather than a 5 because a few concepts (like 'response budget') are explained only implicitly.
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?
For a tool with three parameters including a nested object and an output schema, the description covers all relevant behavior: what the profile returns, the archive page structure, the sections selection, and the budget fallback. Since an output schema exists, the description need not detail return fields. No critical usage aspect is missing, making it complete for an agent to call 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 descriptions cover 100% of parameters with detailed explanations (e.g., ISO3 format, archive list enum values, offset/limit defaults). The tool description adds little new semantic info; it restates the mutual exclusivity of sections/archive, which is also in the schema. Since the schema carries the load, a baseline of 3 is appropriate—the description does not meaningfully enhance parameter understanding beyond what the schema already 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 the verb ('Fetch a country profile'), the resource ('from ReliefWeb by ISO3 code'), and enumerates the profile contents (overview, humanitarian situation summary, etc.). It also distinguishes itself from sibling tools by being country-specific, so an agent can immediately identify its purpose without ambiguous phrasing.
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 the two selectors ('mutually exclusive', 'use archive for those') and explains the archive mode's purpose relative to the profile. However, it does not explicitly contrast with sibling tools like reliefweb_get_disaster, though the resource type makes that implicit. It offers clear internal usage but stops short of saying 'use this when you need a country profile, not a disaster'.
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. Each curated list also has an archive, which the record leaves out. Two alternative selectors, at most one per call: sections names parts of the record to return, archive pages one list's archived entries in place of the record. Description and profile overview can together run to tens of KB for major disasters. A record over the response budget comes back as a section outline naming every section and its byte size. Nothing is truncated on any path.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ReliefWeb numeric disaster ID. Obtained from reliefweb_search_disasters results. | |
| archive | No | Archive mode: return a page of one curated list's ARCHIVED entries instead of the disaster record. The response carries the record identity, the selected list, and total / shown / offset, plus a next offset while more entries remain. Mutually exclusive with sections — sections slices the record, archive replaces it — and a call supplying both is rejected. A record over the response budget still answers an archive call with the page: a page is bounded by limit and carries none of the record prose, so it never outlines. | |
| sections | No | Sections of the disaster record to return, named by the sections[].name values an outline response lists. Omit for the whole record, or for a section outline when the record is over the response budget. Identity metadata — the record's ID, its name, and its canonical URL — comes back alongside whatever is requested. The call is self-contained — the record is re-fetched and sliced, so no prior call has to be repeated. This names parts of the record itself and never reaches archived entries — use archive for those. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | ReliefWeb numeric disaster ID. |
| kind | No | full when the record — or the sections asked for — is returned in whole; outline when the record exceeded the response budget and only its section index is returned; archive when the call asked for a page of one curated list's archived entries, which is returned in place of the record. |
| name | No | Disaster name. |
| error | No | Present when the call failed. Absent on success. |
| glide | No | GLIDE number for cross-system correlation. |
| types | No | Disaster type names. |
| status | No | Disaster status: alert, ongoing, past, or alert-archive. |
| archive | No | One page of a curated list's archived entries, returned in place of the record. |
| sections | No | Every section of the record, largest first. Pass the names back in `sections` to retrieve them. |
| 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 | Currently-active curated key content links from the ReliefWeb editorial team — the present curated set. The archived entries are reachable with archive: { list: "keyContent" }. |
| dateCreated | No | ReliefWeb index date (ISO 8601). |
| description | No | Full disaster description text. |
| primaryType | No | Primary disaster type. |
| usefulLinks | No | Currently-active useful external links curated by ReliefWeb editors — the present set. The archived entries are reachable with archive: { list: "usefulLinks" }. |
| outlineNotice | No | How to re-call this tool for specific sections of the record. |
| primaryCountry | No | Primary affected country. |
| profileOverview | No | Profile overview text from the ReliefWeb editorial team. |
| appealsResponsePlans | No | Currently-active appeals and response plans linked to this disaster — the present set. The archived entries are reachable with archive: { list: "appealsResponsePlans" }. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description goes well beyond by disclosing the size risk ('Description and profile overview can together run to tens of KB'), the outline fallback when over budget, the guarantee that 'Nothing is truncated on any path,' and the archive mode's pagination semantics. This provides rich behavioral context that annotations cannot express.
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 dense but every sentence earns its place. It front-loads the primary purpose, then explains usage context, then details the selectors and edge cases. The structure is clear: main fetch, then two alternative modes, then size behavior. No filler or redundancy; it is long only because it packs precise, non-repeating 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 tool's complexity (two selectors, pagination, outline fallback, size constraints), the description covers all necessary operational aspects. It explains the archive page response structure (identity, list, total/shown/offset, next offset), the sections requirement of exact names from the outline, and the self-contained nature of calls. An output schema exists, so return-value details are not needed; the description fully equips an agent to invoke the tool correctly in all documented scenarios.
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 each parameter (id, archive, sections) is already documented with types, defaults, and descriptions. The description adds critical meaning beyond the schema: it explains the mutual exclusivity of archive and sections, the exact behavior of each selector (archive replaces the record, sections slices it), and how the outline response supplies section names for the sections parameter. This is more than the baseline 3, though the schema already carries heavy weight.
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 states a specific verb ('Fetch') and resource ('disaster record by ReliefWeb numeric ID') and enumerates the returned content (description, affected countries, GLIDE number, profile overview, key content links, active appeals/response plans). It clearly differentiates from sibling search tools by prescribing use after reliefweb_search_disasters and by introducing the archive selector, which is unique to this tool.
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 directs 'Use after reliefweb_search_disasters to retrieve full details.' It further explains when to use the archive parameter (to retrieve archived entries not in the record) and when the sections parameter is needed (to target specific parts or handle oversized records). It also states that a record over the budget returns a section outline, giving a clear contingency path. No alternative tool is named, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reliefweb_get_jobGet ReliefWeb JobARead-onlyIdempotentInspect
Fetch a job posting by ReliefWeb numeric ID with the full vacancy description, application instructions, dates, hiring organization, and location and taxonomy metadata. Use after reliefweb_search_jobs, which returns summaries without the description or application instructions. Reaches expired postings as well as open ones. A record over the response budget comes back as a section outline naming every section and its byte size; re-call with sections to pull only the ones needed. Nothing is truncated on either path.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ReliefWeb numeric job ID. Obtained from reliefweb_search_jobs results. | |
| sections | No | Sections of the job record to return, named by the sections[].name values an outline response lists. Omit for the whole record, or for a section outline when the record is over the response budget. Identity metadata — the record's ID, its name, and its canonical URL — comes back alongside whatever is requested. The call is self-contained — the record is re-fetched and sliced, so no prior call has to be repeated. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | ReliefWeb numeric job ID. |
| url | No | ReliefWeb node URL for this job listing. |
| body | No | Full vacancy description (HTML) — duties, requirements, and conditions. |
| kind | No | full when the record — or the sections asked for — is returned in whole; outline when the record exceeded the response budget and only its section index is returned. |
| error | No | Present when the call failed. Absent on success. |
| title | No | Job title. |
| types | No | Job type names, such as Job or Consultancy. |
| status | No | Posting status: published while the vacancy is open, expired once it has closed. |
| themes | No | Humanitarian theme/sector names. |
| sources | No | Hiring organizations (short names). |
| sections | No | Every section of the record, largest first. Pass the names back in `sections` to retrieve them. |
| urlAlias | No | Canonical ReliefWeb URL for this job listing. |
| countries | No | Countries tagged on this job. |
| howToApply | No | Application instructions (HTML) as published by the hiring organization. |
| dateChanged | No | Date this posting was last modified (ISO 8601). |
| dateClosing | No | Application closing date (ISO 8601). |
| dateCreated | No | Date this posting was indexed (ISO 8601). |
| outlineNotice | No | How to re-call this tool for specific sections of the record. |
| careerCategories | No | Career category names (humanitarian tracks). |
| experienceLevels | No | Required experience levels. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark readOnlyHint, openWorldHint, and idempotentHint, so the description correctly does not repeat those. It adds a crucial behavioral detail: 'Reaches expired postings as well as open ones.' It also fully discloses the response-budget fallback behavior (section outline with byte sizes and the need to re-call with sections) and explicitly guarantees that nothing is truncated on either path. This is thorough, non-redundant behavior disclosure.
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?
Three dense sentences, each earning its place: the first establishes purpose and contents, the second gives usage context, the third covers the edge case and its workaround. No filler or repetition. The key differentiator (full details vs. summaries) is front-loaded, and the response-budget behavior is neatly packaged at the end. Efficiency without sacrificing completeness.
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 simple two-parameter tool, an output schema, and rich annotations, the description covers all necessary facets: purpose, usage sequencing, edge-case handling, and parameter semantics. It explicitly ties the 'sections' parameter to the outline response rather than leaving the agent to guess. Nothing the agent needs to invoke this tool correctly is 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?
The schema covers both parameters at 100%, but the description enriches them substantially. For 'id', it notes it comes from a prior search result. For 'sections', it explains the outline-driven naming, the omission behavior for full record, the inclusion of identity metadata, and the self-contained re-fetch mechanics. This goes well beyond the baseline schema descriptions and gives the agent concrete, actionable parameter semantics.
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 opens with a specific verb ('Fetch') and resource ('a job posting by ReliefWeb numeric ID'), enumerating the contained content (full vacancy description, application instructions, dates, hiring organization, location, taxonomy). It explicitly contrasts with the sibling reliefweb_search_jobs, which returns only summaries, so an agent can immediately distinguish this tool from its search counterpart without inspecting schemas.
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?
It states exactly when to use this tool: 'Use after reliefweb_search_jobs, which returns summaries without the description or application instructions.' This names the alternative and the condition that selects this tool. It also explains the workflow for the over-budget case (outline response then re-call with sections), giving the agent concrete steps to follow.
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. A record over the response budget comes back as a section outline naming every section and its byte size; re-call with sections to pull only the ones needed. Nothing is truncated on either path.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ReliefWeb numeric report ID. Obtained from reliefweb_search_reports results. | |
| sections | No | Sections of the report record to return, named by the sections[].name values an outline response lists. Omit for the whole record, or for a section outline when the record is over the response budget. Identity metadata — the record's ID, its name, and its canonical URL — comes back alongside whatever is requested. The call is self-contained — the record is re-fetched and sliced, so no prior call has to be repeated. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | ReliefWeb numeric report ID. |
| body | No | Full report body text (HTML). Present for most reports; absent for binary-only documents. |
| kind | No | full when the record — or the sections asked for — is returned in whole; outline when the record exceeded the response budget and only its section index is returned. |
| error | No | Present when the call failed. Absent on success. |
| title | No | 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. |
| sections | No | Every section of the record, largest first. Pass the names back in `sections` to retrieve them. |
| 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). |
| outlineNotice | No | How to re-call this tool for specific sections of the record. |
| primaryCountry | No | Primary country name for this report. |
| headlineSummary | No | Short editorial summary from the headline block, when present. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds non-contradicting richness: it discloses that report bodies can be 10–100KB, that over-budget records return a section outline with byte sizes, and that 'Nothing is truncated on either path.' This tells the agent exactly what to expect for large payloads without having to discover it. The explanation that the call is self-contained ('record is re-fetched and sliced') adds operational transparency beyond the schema.
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 dense but every sentence earns its place. The first sentence establishes purpose, the second provides usage context, and the remaining sentences explain the size-handling behavior and self-containment. It is front-loaded with the action, flows logically, and contains no redundant phrasing.
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 the tool has only two parameters, an existing output schema, and safety annotations, the description covers all necessary operational details: how to obtain the ID, when to use sections, what happens for large reports, and that no truncation occurs. It even notes that identity metadata is always included. An agent can correctly invoke this tool with no ambiguity.
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 the baseline is 3, but the description adds meaning beyond field definitions. It clarifies that 'sections' values must match exactly as the outline spelled them, and explains the behavior of omitting sections (whole record vs. outline for over-budget records). This transforms a vague array parameter into a well-understood control for response size management.
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 opens with 'Fetch a single ReliefWeb report by its numeric ID with full body text, file attachments, and all metadata,' which is a specific verb plus resource and scope. It differentiates from siblings by explicitly instructing 'Use after reliefweb_search_reports to retrieve document content,' making it clear this is the report-specific retrieval tool versus other resource fetchers.
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 when-to-use guidance: 'Use after reliefweb_search_reports' and explains why body is excluded from search results. It also details the conditional behavior for large reports (over response budget → outline → re-call with sections), giving the agent a concrete decision path for handling oversized responses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reliefweb_get_trainingGet ReliefWeb TrainingARead-onlyIdempotentInspect
Fetch a training listing by ReliefWeb numeric ID with the full description, registration instructions, event link, cost and fee information, dates, languages, and organizing source. Use after reliefweb_search_training, which returns summaries without the description, registration instructions, or cost detail. Reaches concluded listings as well as current ones. A record over the response budget comes back as a section outline naming every section and its byte size; re-call with sections to pull only the ones needed. Nothing is truncated on either path.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ReliefWeb numeric training ID. Obtained from reliefweb_search_training results. | |
| sections | No | Sections of the training record to return, named by the sections[].name values an outline response lists. Omit for the whole record, or for a section outline when the record is over the response budget. Identity metadata — the record's ID, its name, and its canonical URL — comes back alongside whatever is requested. The call is self-contained — the record is re-fetched and sliced, so no prior call has to be repeated. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | ReliefWeb numeric training ID. |
| url | No | ReliefWeb node URL for this training listing. |
| body | No | Full training description (HTML) — content, audience, and logistics. |
| cost | No | Cost class as ReliefWeb records it, such as free or fee-based. |
| kind | No | full when the record — or the sections asked for — is returned in whole; outline when the record exceeded the response budget and only its section index is returned. |
| error | No | Present when the call failed. Absent on success. |
| title | No | Training title. |
| types | No | Training type names, such as Training/Workshop or Course. |
| cities | No | Host cities, for on-site training. |
| status | No | Listing status: published while the training is current, expired once concluded. |
| themes | No | Humanitarian theme/sector names. |
| dateEnd | No | Training end date (ISO 8601). |
| formats | No | Training format names: on-site or online. |
| sources | No | Organizing organizations (short names). |
| eventUrl | No | The organizer's own page for this training, when published. |
| sections | No | Every section of the record, largest first. Pass the names back in `sections` to retrieve them. |
| urlAlias | No | Canonical ReliefWeb URL for this training listing. |
| countries | No | Countries tagged on this training. |
| dateStart | No | Training start date (ISO 8601). |
| languages | No | Language codes of the listing (ISO 639-1). |
| dateCreated | No | Date this listing was indexed (ISO 8601). |
| howToRegister | No | Registration instructions (HTML) as published by the organizer. |
| outlineNotice | No | How to re-call this tool for specific sections of the record. |
| feeInformation | No | Fee detail as published by the organizer — amounts, inclusions, and conditions. |
| careerCategories | No | Career category names (humanitarian tracks). |
| dateRegistration | No | Registration deadline (ISO 8601). |
| trainingLanguages | No | Language codes the training is delivered in (ISO 639-1). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, openWorld, and idempotent hints. The description adds valuable behavioral context beyond annotations: it mentions reaching concluded listings as well as current ones, and explains the two response paths—full record when under budget, section outline over budget—with the promise that nothing is truncated. This goes beyond what annotations convey and gives the agent a clear mental model of the tool's behavior.
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 yet information-dense. It leads with the core action and data fields, immediately contrasts with the sibling search tool, then explains the budget behavior and the sections mechanism. Every sentence serves a purpose—no filler or repetition. It is appropriately front-loaded and easy to scan.
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 (fetch by ID, optional sections), the description covers all needed context: what it returns, when to use it (after search), how to handle over-budget responses, and the response guarantee (no truncation). An output schema exists, so return value details are covered. It also differentiates from all 10 siblings effectively. Nothing an agent needs to call it correctly is 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?
The input schema has 100% description coverage, so the baseline is 3. The description enhances parameter meaning by explaining that the 'sections' parameter expects names from an outline response and clarifies the self-contained nature (re-fetches and slices, no repeated calls). It also adds the note about identity metadata always being returned. These details go beyond the schema descriptions and help the agent use parameters correctly, justifying 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 precisely states the action ('Fetch a training listing by ReliefWeb numeric ID') and enumerates the exact data included (full description, registration instructions, event link, cost/fee, dates, languages, organizing source). It explicitly contrasts with the sibling tool (reliefweb_search_training) which returns summaries, so an agent can easily distinguish it from other get_* siblings.
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 gives explicit when-to-use guidance: 'Use after reliefweb_search_training' and explains the difference (search returns summaries without description, registration instructions, or cost detail). It also instructs on the sections parameter for over-budget responses, covering both normal and edge-case usage. No ambiguity about when to select this tool.
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 ongoing). Default false returns all countries. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| items | No | Countries tracked by ReliefWeb. |
| notice | No | Present 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. |
| totalCount | No | Total countries matching the filter before pagination. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, openWorld, and idempotent hints. The description adds valuable behavioral context by stating what is returned (ISO3 codes and status) and how the optional filter affects results ('crisis_only=true to limit results to countries with active humanitarian situations'). This goes beyond the annotations without contradicting them.
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 no filler. The core function and output are front-loaded, followed by the filter usage and a pointer to the sibling. Every word contributes 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 the output schema exists and annotations cover safety, the description is sufficient. It mentions the key output fields, the optional filter, and points to the sibling for full details. The pagination and rate limit are already in the schema, so nothing critical is 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% with detailed descriptions for limit, offset, and crisis_only, so the description adds little beyond reminding the agent to use crisis_only. The baseline is 3 because the schema carries the parameter semantics; the description does not introduce new 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 states a specific verb ('List') and resource ('all countries and territories tracked by ReliefWeb'), distinguishes from the sibling reliefweb_get_country by noting it returns a list, and clarifies the optional crisis filter. This clearly differentiates it from the other list/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?
The description provides an explicit alternative: 'use the ISO3 code with reliefweb_get_country to fetch a full profile.' It also gives a usage condition for crisis_only. However, it does not explicitly state when NOT to use this tool compared to the search tools (e.g., when a country-specific query is needed), but the given guidance is sufficient for the main alternative.
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. One of: Non-governmental Organization, International Organization, Academic and Research Institution, Other, Government, Media, Red Cross/Red Crescent Movement. 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 |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| items | No | Source organizations contributing content to ReliefWeb. |
| notice | No | Present 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. |
| totalCount | No | Total sources matching the query before pagination. |
TDQS
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.
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.
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.
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.
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.
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.
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, ongoing, and past disasters. Use include_archived=true to reach alert-archive entries as well, 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. One of: alert (newly declared), ongoing, past (resolved), alert-archive. Separate multiple values with commas; case, spacing, and punctuation are ignored, and any other value is rejected with the valid list. alert-archive is only reachable with include_archived=true — asking for it without that returns nothing. | |
| country | No | ISO 3166-1 alpha-3 country code (e.g., SYR, AFG, UKR). Filters to disasters tagged with this country. | |
| date_to | No | Latest disaster creation date. Pair with date_from for a date range. A bare calendar date resolves to end of that day in UTC, so the range covers it in full; a datetime carrying any offset is resolved to UTC. | |
| date_from | No | Earliest disaster creation date. Filters on date.created. A bare calendar date such as 2024-01-15 is accepted and resolves to start of that day in UTC; a datetime carrying any offset is resolved to UTC. | |
| disaster_type | No | Disaster type name (e.g., Earthquake, Flood, Drought, Cyclone). Filters on type.name. | |
| include_archived | No | Include alert-archive disasters in results, alongside alert, ongoing, and past. Uses preset=analysis. Off by default. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| items | No | Matching disasters. |
| notice | No | Present 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. |
| totalCount | No | Total disasters matching the query before pagination. |
| appliedFilters | No | 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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant detail beyond annotations: default preset behavior, archived reachability, quota limit per call (1,000/day), status value validation, and date resolution semantics. The readOnlyHint and idempotentHint are already present, and the description complements them with operational behavior like pagination via totalCount enrichment field.
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, followed by a critical filtering nuance and a chaining hint. Every sentence earns its place with no redundancy or filler.
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 11-parameter complexity, an output schema for results, and read-only/idempotent annotations, the description covers all essential aspects: defaults, archived behavior, quota, date handling, and downstream usage. An agent has sufficient information to invoke correctly without additional lookups.
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's meaning is already documented thoroughly in the schema. The tool description repeats the overall filter categories but does not add new semantic detail beyond what the schema provides. Baseline of 3 is appropriate.
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 specific verb ('search'), resource ('disasters on ReliefWeb'), and the filter criteria (type, country, status, date range, GLIDE number). It differentiates from sibling tools by mentioning returned IDs suitable for reliefweb_get_disaster and as disaster_id filter in reliefweb_search_reports, establishing its role in a workflow.
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 clear guidance on when to use include_archived=true for historical research and default preset coverage. Names related siblings for chaining. However, it does not explicitly state when to prefer this search over reliefweb_get_disaster for single-record retrieval, leaving some inference to the agent.
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 — expired postings are excluded by default. Use include_archived=true to search the full history of postings, which is far larger than the open set. Use text search for role titles and job descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order. Use date.created:desc for newest postings first (default), date.closing:asc to surface roles closing soonest, or score:desc for relevance. | |
| 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. | |
| include_archived | No | Search expired postings alongside the open ones. Uses preset=analysis. Off by default — the open set is a small fraction of the archive, so turn this on for labour-market history rather than for a hiring snapshot. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| items | No | Matching job listings. |
| notice | No | Present 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. |
| totalCount | No | Total jobs matching the query before pagination. |
| appliedFilters | No | 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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful behavioral context: expired postings are excluded by default, the archived set is 'far larger', and include_archived uses preset=analysis. These details go beyond annotations and clarify the default scope and the trade-off of turning on archiving.
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 four succinct sentences, all informative. It front-loads the main purpose and filters, then covers the default behavior, the archived option, and the text search hint. Every sentence earns its place with no filler.
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?
For a search tool with ten well-documented parameters, an output schema, and annotations that cover safety, the description is complete. It resolves the key ambiguity between open and archived postings, provides scaling context, and gives practical usage guidance. Nothing an agent needs to call it correctly is 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%, so parameters are fully documented. The description adds semantic value for include_archived by explaining its purpose (searching full history) and the scale difference, and for text by stating it matches titles and descriptions. These enrich the schema descriptions without redundancy.
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 verb 'Search' and the resource 'humanitarian job listings on ReliefWeb', identifies the filtering dimensions (country, organization, career category, theme, experience level), and explicitly notes that it returns current open positions with expired postings excluded by default. It distinguishes itself from sibling tools like get_job by implying a search over a set rather than a single record.
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 clear context for when to enable include_archived (for full history vs. current snapshot) and when to use text search (for role titles and job descriptions). However, it does not explicitly mention alternatives like get_job for fetching a single job by ID, so the routing to siblings is left implicit.
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. Every report is reachable by default — reports have no archived class, so include_archived has no effect here. Note: each call counts against the 1,000 calls/day quota.
| 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 Non-Food Items, Protection). Open-ended — matches theme.name exactly as ReliefWeb spells it. | |
| 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. One of: News and Press Release, Situation Report, Map, Infographic, Analysis, Other, Assessment, Manual and Guideline, Appeal, UN Document, Evaluation and Lessons Learned. Case, spacing, and punctuation are ignored; any other value is rejected with the valid list. | |
| 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. Pair with date_from for a date range. A bare calendar date resolves to end of that day in UTC, so the range covers it in full; a datetime carrying any offset is resolved to UTC. | |
| language | No | ISO 639-1 language code (e.g., en, fr, es, ar). Filters on language.code. | |
| date_from | No | Earliest publication date. Filters on date.original (source publication date). A bare calendar date such as 2024-01-15 is accepted and resolves to start of that day in UTC; a datetime carrying any offset is resolved to UTC. | |
| disaster_id | No | ReliefWeb numeric disaster ID. Filters to reports linked to a specific disaster. Get the ID from reliefweb_search_disasters. | |
| include_archived | No | No effect on reports. Reports have no archived class — every report is already in scope, whatever this is set to. Kept so existing calls that pass it keep working; it is meaningful on reliefweb_search_jobs, reliefweb_search_training, and reliefweb_search_disasters. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| items | No | Matching reports (summaries only — use reliefweb_get_report for full body). |
| notice | No | Present 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. |
| totalCount | No | Total reports matching the query before pagination. |
| appliedFilters | No | 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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it notes that report bodies are excluded from results (with size estimates), that include_archived has no effect on reports, and that each call counts against a 1,000/day quota. This gives the agent important operational constraints not evident from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise given the tool's complexity (14 parameters, many with nuanced behavior). It front-loads the core purpose and quickly notes the key limitation (no body text, use get_report). Every sentence serves a purpose—mentioning pagination, quota, and include_archived behavior. It's structured logically but could be slightly tightened to avoid repeating 'each call counts' twice, though that repetition reinforces an important constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 14 parameters, nested objects, and an output schema. The description covers the essential operational details: what the tool returns (paginated summaries without body text), when to use the sibling get_report, the archiving caveat, the quota impact, and how to page. The output schema likely describes the response structure, so the description doesn't need to enumerate return fields. It's complete for an agent to correctly invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every parameter has a description. The description adds modest extra value beyond the schema—for instance, it explains that the text parameter matches against title, body, and metadata, and it clarifies the behavior of date_from/date_to with timezone resolution. However, most parameter details are already in the schema, so the baseline of 3 is appropriate; the description doesn't significantly elevate parameter understanding beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches humanitarian reports with specific filters (country, disaster, format, theme, language, source, date) and returns paginated summaries. It distinguishes itself from sibling tools by explicitly mentioning reliefweb_get_report for full body text, which separates search from retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides solid guidance on when to use this tool versus reliefweb_get_report (when full body is needed) and explains that include_archived has no effect on reports, directing users to sibling tools where it is meaningful. However, it doesn't explicitly state when to prefer this over reliefweb_search_disasters or other search tools, though the 'search reports' focus implicitly covers it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reliefweb_search_trainingSearch ReliefWeb TrainingARead-onlyIdempotentInspect
Search humanitarian training and learning opportunities on ReliefWeb by country, format, date, source, career category, and language. Covers on-site and online 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. Results default to soonest-starting first (date.start:asc). With neither date bound supplied the search is scoped to training starting from now, so the first page is upcoming opportunities; supply either bound to search an explicit range, including a historical one. Use include_archived=true to search concluded listings as well, which are far more numerous than the current ones.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order. Use date.start:asc for soonest-starting training first (default), date.start:desc for latest-starting, date.created:desc for most recently posted, or score:desc for relevance. | |
| 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. Valid values: on-site, online. 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. Filters on date.start — pair with date_start_from for a window. A bare calendar date resolves to end of that day in UTC, and a datetime carrying any offset is resolved to UTC. Supplying this alone searches everything up to it, with no lower bound injected. | |
| 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. Filters on date.start — use to find training starting after a given date. A bare calendar date resolves to start of that day in UTC, and a datetime carrying any offset is resolved to UTC. Omit this and date_start_to together to default the search to training starting from now, unless include_archived is set, which leaves the range open. | |
| include_archived | No | Search concluded listings alongside the current ones. Uses preset=analysis. Off by default. Setting this also drops the start-from-now default bound, so an otherwise unbounded search reaches back through the whole record; pair it with date_start_from and date_start_to to study a specific period. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| items | No | Matching training opportunities. |
| notice | No | Present 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. |
| totalCount | No | Total training listings matching the query before pagination. |
| appliedFilters | No | 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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description reveals default sorting (date.start:asc), the implicit date scoping when no bounds are supplied, the effect of include_archived on the range, and warns that training date fields are different from report date fields. These behavioral details are not present in the annotations or schema, adding substantial value.
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 a single, compact paragraph with no fluff. It front-loads the purpose, then packs key behavioral rules (date field difference, sorting, default scoping, archived inclusion) into a few sentences. Every sentence contributes distinctive information, achieving high information density without being verbose.
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 12 parameters, 100% schema coverage, and an existing output schema, the description concentrates on the non-obvious aspects: default date range behavior, sorting defaults, and the archived toggle. It also flags the field naming difference from other tools. No critical operational ambiguity remains that would prevent an agent from calling it 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?
The schema already provides 100% coverage with rich descriptions for each parameter. The description adds meaningful interaction semantics: how date_start_from/date_start_to work together to define a window, the default behavior when both are omitted, and the consequence of include_archived on the range. This goes beyond the schema's individual parameter explanations.
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' with specific filters (country, format, date, source, career category, language). It distinguishes this from sibling search tools (reports, jobs) by explicitly focusing on 'training', and clarifies it covers on-site and online capacity-building events. This is a specific verb + resource with clear 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?
Provides explicit guidance on using date bounds for windows, the default start-from-now behavior, and when to use include_archived. It notes that training date fields differ from report date fields, which is a subtle usage hint. However, it doesn't explicitly name alternative sibling tools for non-training queries, so it stops short of a full 'when-not-to-use' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
11 tool updates
- Changed
reliefweb_get_country6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "kind" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: No country profile found for the given ISO3 code. `selector_conflict`: The call supplied both sections and archive, which select different things. Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found", + "selector_conflict" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "kind" -]
- Changed
reliefweb_get_disaster6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "kind" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: No disaster found with the given ID. `selector_conflict`: The call supplied both sections and archive, which select different things. Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found", + "selector_conflict" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "kind" -]
- Changed
reliefweb_get_job6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "kind" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: No job posting found with the given ID. Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "kind" -]
- Changed
reliefweb_get_report6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "kind" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: No report found with the given ID. Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "kind" -]
- Changed
reliefweb_get_training6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "kind" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: No training listing found with the given ID. Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "kind" -]
- Changed
reliefweb_list_countries6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "items", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `invalid_query`: ReliefWeb rejected the request as malformed rather than failing to serve it. `upstream_error`: The ReliefWeb API was unreachable, timed out, or returned a server error. Other values are possible when a failure originates below the handler.", + "examples": [ + "invalid_query", + "upstream_error" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "items", - "totalCount" -]
- Changed
reliefweb_list_sources6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "items", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `invalid_query`: ReliefWeb rejected the request as malformed rather than failing to serve it. `upstream_error`: The ReliefWeb API was unreachable, timed out, or returned a server error. Other values are possible when a failure originates below the handler.", + "examples": [ + "invalid_query", + "upstream_error" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "items", - "totalCount" -]
- Changed
reliefweb_search_disasters6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "items", + "appliedFilters", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `unknown_status`: A status token does not name a ReliefWeb disaster status. `invalid_query`: ReliefWeb rejected the query — an unrecognized sort field or a malformed date. `upstream_error`: The ReliefWeb API was unreachable, timed out, or returned a server error. Other values are possible when a failure originates below the handler.", + "examples": [ + "unknown_status", + "invalid_query", + "upstream_error" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "items", - "appliedFilters", - "totalCount" -]
- Changed
reliefweb_search_jobs6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "items", + "appliedFilters", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `invalid_query`: ReliefWeb rejected the query — typically an unrecognized sort field. `upstream_error`: The ReliefWeb API was unreachable, timed out, or returned a server error. Other values are possible when a failure originates below the handler.", + "examples": [ + "invalid_query", + "upstream_error" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "items", - "appliedFilters", - "totalCount" -]
- Changed
reliefweb_search_reports6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "items", + "appliedFilters", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `unknown_format`: The format value does not name a ReliefWeb report format. `invalid_query`: ReliefWeb rejected the query — an unrecognized sort field, an invalid raw filter object, or a malformed date. `upstream_error`: The ReliefWeb API was unreachable, timed out, or returned a server error. Other values are possible when a failure originates below the handler.", + "examples": [ + "unknown_format", + "invalid_query", + "upstream_error" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "items", - "appliedFilters", - "totalCount" -]
- Changed
reliefweb_search_training6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "items", + "appliedFilters", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `invalid_query`: ReliefWeb rejected the query — an unrecognized sort field or a malformed date. `upstream_error`: The ReliefWeb API was unreachable, timed out, or returned a server error. Other values are possible when a failure originates below the handler.", + "examples": [ + "invalid_query", + "upstream_error" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "items", - "appliedFilters", - "totalCount" -]
5 tool updates
- Changed
reliefweb_get_country10 fields changed- added
Input schema / properties / archiveAdded value: +{ + "description": "Archive mode: return a page of one curated list's ARCHIVED entries instead of the country record. The response carries the record identity, the selected list, and total / shown / offset, plus a next offset while more entries remain. Mutually exclusive with sections — sections slices the record, archive replaces it — and a call supplying both is rejected. A record over the response budget still answers an archive call with the page: a page is bounded by limit and carries none of the record prose, so it never outlines.", + "properties": { + "limit": { + "default": 25, + "description": "Maximum archived entries in one page (1-100).", + "maximum": 100, + "minimum": 1, + "type": "integer" + }, + "list": { + "description": "Which curated list to page. The archived entries of that list are the ones the profile itself leaves out.", + "enum": [ + "keyContent", + "appealsResponsePlans", + "usefulLinks" + ], + "type": "string" + }, + "offset": { + "default": 0, + "description": "Zero-based index of the first archived entry to return. Send back the nextOffset from the previous page to continue.", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "list" + ], + "type": "object" +} - added
Input schema / properties / sectionsAdded value: +{ + "description": "Sections of the country record to return, named by the sections[].name values an outline response lists. Omit for the whole record, or for a section outline when the record is over the response budget. Identity metadata — the record's ID, its name, and its canonical URL — comes back alongside whatever is requested. The call is self-contained — the record is re-fetched and sliced, so no prior call has to be repeated. This names parts of the profile itself and never reaches archived entries — use archive for those.", + "items": { + "description": "A section name exactly as the outline response spelled it.", + "type": "string" + }, + "type": "array" +} - changed
Output schema / properties / appealsResponsePlans / descriptionPrevious value: -"Currently-active humanitarian appeals and response plans for this country — the present set, not the full historical archive."New value: +"Currently-active humanitarian appeals and response plans for this country — the present set. The archived entries are reachable with archive: { list: \"appealsResponsePlans\" }." - added
Output schema / properties / archiveAdded value: +{ + "additionalProperties": false, + "description": "One page of a curated list's archived entries, returned in place of the record.", + "properties": { + "entries": { + "description": "The archived entries in this page, in ReliefWeb's own archive order.", + "items": { + "additionalProperties": false, + "description": "One archived entry.", + "properties": { + "date": { + "description": "Publication date, carried by appeals and response plans.", + "type": "string" + }, + "title": { + "description": "Entry title.", + "type": "string" + }, + "url": { + "description": "Entry URL.", + "type": "string" + } + }, + "required": [ + "title", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "list": { + "description": "The curated list this page was read from.", + "enum": [ + "keyContent", + "appealsResponsePlans", + "usefulLinks" + ], + "type": "string" + }, + "nextOffset": { + "description": "Offset to send back to read the next page. Absent when this page reaches the end of the archive.", + "type": "number" + }, + "offset": { + "description": "Zero-based index of the first entry in this page.", + "type": "number" + }, + "shown": { + "description": "Number of entries in this page.", + "type": "number" + }, + "total": { + "description": "Total archived entries in that list for this record.", + "type": "number" + } + }, + "required": [ + "list", + "total", + "shown", + "offset", + "entries" + ], + "type": "object" +} - changed
Output schema / properties / keyContent / descriptionPrevious value: -"Currently-active curated key content links maintained by ReliefWeb editors — the present curated set, not the full historical archive."New value: +"Currently-active curated key content links maintained by ReliefWeb editors — the present curated set. The archived entries are reachable with archive: { list: \"keyContent\" }." - added
Output schema / properties / kindAdded value: +{ + "description": "full when the record — or the sections asked for — is returned in whole; outline when the record exceeded the response budget and only its section index is returned; archive when the call asked for a page of one curated list's archived entries, which is returned in place of the record.", + "enum": [ + "full", + "outline", + "archive" + ], + "type": "string" +} - added
Output schema / properties / outlineNoticeAdded value: +{ + "description": "How to re-call this tool for specific sections of the record.", + "type": "string" +} - added
Output schema / properties / sectionsAdded value: +{ + "description": "Every section of the record, largest first. Pass the names back in `sections` to retrieve them.", + "items": { + "additionalProperties": false, + "description": "One retrievable section of the record: its name and its serialized size.", + "properties": { + "bytes": { + "description": "Serialized byte size of the section", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "name": { + "description": "Section identifier — pass in `sections` to retrieve it", + "type": "string" + } + }, + "required": [ + "name", + "bytes" + ], + "type": "object" + }, + "type": "array" +} - changed
Output schema / properties / usefulLinks / descriptionPrevious value: -"Currently-active useful external links curated by ReliefWeb editors — the present set, not the full historical archive."New value: +"Currently-active useful external links curated by ReliefWeb editors — the present set. The archived entries are reachable with archive: { list: \"usefulLinks\" }." - changed
Output schema / requiredPrevious value: -[ - "id", - "name" -]New value: +[ + "kind" +]
- Changed
reliefweb_get_disaster10 fields changed- added
Input schema / properties / archiveAdded value: +{ + "description": "Archive mode: return a page of one curated list's ARCHIVED entries instead of the disaster record. The response carries the record identity, the selected list, and total / shown / offset, plus a next offset while more entries remain. Mutually exclusive with sections — sections slices the record, archive replaces it — and a call supplying both is rejected. A record over the response budget still answers an archive call with the page: a page is bounded by limit and carries none of the record prose, so it never outlines.", + "properties": { + "limit": { + "default": 25, + "description": "Maximum archived entries in one page (1-100).", + "maximum": 100, + "minimum": 1, + "type": "integer" + }, + "list": { + "description": "Which curated list to page. The archived entries of that list are the ones the profile itself leaves out.", + "enum": [ + "keyContent", + "appealsResponsePlans", + "usefulLinks" + ], + "type": "string" + }, + "offset": { + "default": 0, + "description": "Zero-based index of the first archived entry to return. Send back the nextOffset from the previous page to continue.", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "list" + ], + "type": "object" +} - added
Input schema / properties / sectionsAdded value: +{ + "description": "Sections of the disaster record to return, named by the sections[].name values an outline response lists. Omit for the whole record, or for a section outline when the record is over the response budget. Identity metadata — the record's ID, its name, and its canonical URL — comes back alongside whatever is requested. The call is self-contained — the record is re-fetched and sliced, so no prior call has to be repeated. This names parts of the record itself and never reaches archived entries — use archive for those.", + "items": { + "description": "A section name exactly as the outline response spelled it.", + "type": "string" + }, + "type": "array" +} - changed
Output schema / properties / appealsResponsePlans / descriptionPrevious value: -"Currently-active appeals and response plans linked to this disaster — the present set, not the full historical archive."New value: +"Currently-active appeals and response plans linked to this disaster — the present set. The archived entries are reachable with archive: { list: \"appealsResponsePlans\" }." - added
Output schema / properties / archiveAdded value: +{ + "additionalProperties": false, + "description": "One page of a curated list's archived entries, returned in place of the record.", + "properties": { + "entries": { + "description": "The archived entries in this page, in ReliefWeb's own archive order.", + "items": { + "additionalProperties": false, + "description": "One archived entry.", + "properties": { + "date": { + "description": "Publication date, carried by appeals and response plans.", + "type": "string" + }, + "title": { + "description": "Entry title.", + "type": "string" + }, + "url": { + "description": "Entry URL.", + "type": "string" + } + }, + "required": [ + "title", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "list": { + "description": "The curated list this page was read from.", + "enum": [ + "keyContent", + "appealsResponsePlans", + "usefulLinks" + ], + "type": "string" + }, + "nextOffset": { + "description": "Offset to send back to read the next page. Absent when this page reaches the end of the archive.", + "type": "number" + }, + "offset": { + "description": "Zero-based index of the first entry in this page.", + "type": "number" + }, + "shown": { + "description": "Number of entries in this page.", + "type": "number" + }, + "total": { + "description": "Total archived entries in that list for this record.", + "type": "number" + } + }, + "required": [ + "list", + "total", + "shown", + "offset", + "entries" + ], + "type": "object" +} - changed
Output schema / properties / keyContent / descriptionPrevious value: -"Currently-active curated key content links from the ReliefWeb editorial team — the present curated set, not the full historical archive."New value: +"Currently-active curated key content links from the ReliefWeb editorial team — the present curated set. The archived entries are reachable with archive: { list: \"keyContent\" }." - added
Output schema / properties / kindAdded value: +{ + "description": "full when the record — or the sections asked for — is returned in whole; outline when the record exceeded the response budget and only its section index is returned; archive when the call asked for a page of one curated list's archived entries, which is returned in place of the record.", + "enum": [ + "full", + "outline", + "archive" + ], + "type": "string" +} - added
Output schema / properties / outlineNoticeAdded value: +{ + "description": "How to re-call this tool for specific sections of the record.", + "type": "string" +} - added
Output schema / properties / sectionsAdded value: +{ + "description": "Every section of the record, largest first. Pass the names back in `sections` to retrieve them.", + "items": { + "additionalProperties": false, + "description": "One retrievable section of the record: its name and its serialized size.", + "properties": { + "bytes": { + "description": "Serialized byte size of the section", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "name": { + "description": "Section identifier — pass in `sections` to retrieve it", + "type": "string" + } + }, + "required": [ + "name", + "bytes" + ], + "type": "object" + }, + "type": "array" +} - changed
Output schema / properties / usefulLinks / descriptionPrevious value: -"Currently-active useful external links curated by ReliefWeb editors — the present set, not the full historical archive."New value: +"Currently-active useful external links curated by ReliefWeb editors — the present set. The archived entries are reachable with archive: { list: \"usefulLinks\" }." - changed
Output schema / requiredPrevious value: -[ - "id", - "name" -]New value: +[ + "kind" +]
- Added
reliefweb_get_job - Changed
reliefweb_get_report5 fields changed- added
Input schema / properties / sectionsAdded value: +{ + "description": "Sections of the report record to return, named by the sections[].name values an outline response lists. Omit for the whole record, or for a section outline when the record is over the response budget. Identity metadata — the record's ID, its name, and its canonical URL — comes back alongside whatever is requested. The call is self-contained — the record is re-fetched and sliced, so no prior call has to be repeated.", + "items": { + "description": "A section name exactly as the outline response spelled it.", + "type": "string" + }, + "type": "array" +} - added
Output schema / properties / kindAdded value: +{ + "description": "full when the record — or the sections asked for — is returned in whole; outline when the record exceeded the response budget and only its section index is returned.", + "enum": [ + "full", + "outline" + ], + "type": "string" +} - added
Output schema / properties / outlineNoticeAdded value: +{ + "description": "How to re-call this tool for specific sections of the record.", + "type": "string" +} - added
Output schema / properties / sectionsAdded value: +{ + "description": "Every section of the record, largest first. Pass the names back in `sections` to retrieve them.", + "items": { + "additionalProperties": false, + "description": "One retrievable section of the record: its name and its serialized size.", + "properties": { + "bytes": { + "description": "Serialized byte size of the section", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "name": { + "description": "Section identifier — pass in `sections` to retrieve it", + "type": "string" + } + }, + "required": [ + "name", + "bytes" + ], + "type": "object" + }, + "type": "array" +} - changed
Output schema / requiredPrevious value: -[ - "id", - "title" -]New value: +[ + "kind" +]
- Added
reliefweb_get_training
5 tool updates
- Changed
reliefweb_get_disaster1 field changed- changed
Output schema / properties / status / descriptionPrevious value: -"Disaster status (alert, current, past, archive)."New value: +"Disaster status: alert, ongoing, past, or alert-archive."
- Changed
reliefweb_search_disasters4 fields changed- changed
Input schema / properties / include_archived / descriptionPrevious value: -"Include alert-archive and archive disasters in results. Uses preset=analysis. Off by default."New value: +"Include alert-archive disasters in results, alongside alert, ongoing, and past. Uses preset=analysis. Off by default." - changed
Input schema / properties / status / descriptionPrevious value: -"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."New value: +"Disaster status filter. One of: alert (newly declared), ongoing, past (resolved), alert-archive. Separate multiple values with commas; case, spacing, and punctuation are ignored, and any other value is rejected with the valid list. alert-archive is only reachable with include_archived=true — asking for it without that returns nothing." - changed
Output schema / properties / appliedFilters / properties / status / descriptionPrevious value: -"Status filter applied (comma-joined when multiple)."New value: +"Status filter applied, in canonical spelling (comma-joined when multiple)." - changed
Output schema / properties / items / items / properties / status / descriptionPrevious value: -"Disaster status (alert, current, past, archive)."New value: +"Disaster status: alert, ongoing, past, or alert-archive."
- Changed
reliefweb_search_jobs3 fields changed- added
Input schema / properties / include_archivedAdded value: +{ + "description": "Search expired postings alongside the open ones. Uses preset=analysis. Off by default — the open set is a small fraction of the archive, so turn this on for labour-market history rather than for a hiring snapshot.", + "type": "boolean" +} - added
Output schema / properties / appliedFilters / properties / presetAdded value: +{ + "description": "ReliefWeb preset the query used: latest (open postings only, default) or analysis when include_archived.", + "type": "string" +} - changed
Output schema / properties / appliedFilters / requiredPrevious value: -[ - "sort", - "limit", - "offset" -]New value: +[ + "sort", + "preset", + "limit", + "offset" +]
- Changed
reliefweb_search_reports5 fields changed- changed
Input schema / properties / format / descriptionPrevious value: -"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."New value: +"Content format filter. One of: News and Press Release, Situation Report, Map, Infographic, Analysis, Other, Assessment, Manual and Guideline, Appeal, UN Document, Evaluation and Lessons Learned. Case, spacing, and punctuation are ignored; any other value is rejected with the valid list." - changed
Input schema / properties / include_archived / descriptionPrevious value: -"Include archived and to-review content in addition to published. Uses preset=analysis. Off by default."New value: +"No effect on reports. Reports have no archived class — every report is already in scope, whatever this is set to. Kept so existing calls that pass it keep working; it is meaningful on reliefweb_search_jobs, reliefweb_search_training, and reliefweb_search_disasters." - changed
Input schema / properties / theme / descriptionPrevious value: -"Sector or cross-cutting theme (e.g., Health, Food and Nutrition, Shelter and NFI, Protection). Matches theme.name."New value: +"Sector or cross-cutting theme (e.g., Health, Food and Nutrition, Shelter and Non-Food Items, Protection). Open-ended — matches theme.name exactly as ReliefWeb spells it." - changed
Output schema / properties / appliedFilters / properties / format / descriptionPrevious value: -"Format name filter applied."New value: +"Format name filter applied, in its canonical ReliefWeb spelling." - changed
Output schema / properties / appliedFilters / properties / preset / descriptionPrevious value: -"ReliefWeb preset the query used: latest (default) or analysis when include_archived."New value: +"ReliefWeb preset the query used. Always latest for reports — no preset changes which reports match."
- Changed
reliefweb_search_training5 fields changed- changed
Input schema / properties / date_start_from / descriptionPrevious value: -"Training start date lower bound. Filters on date.start — use to find training starting after a given date. A bare calendar date resolves to start of that day in UTC, and a datetime carrying any offset is resolved to UTC. Omit this and date_start_to together to default the search to training starting from now."New value: +"Training start date lower bound. Filters on date.start — use to find training starting after a given date. A bare calendar date resolves to start of that day in UTC, and a datetime carrying any offset is resolved to UTC. Omit this and date_start_to together to default the search to training starting from now, unless include_archived is set, which leaves the range open." - added
Input schema / properties / include_archivedAdded value: +{ + "description": "Search concluded listings alongside the current ones. Uses preset=analysis. Off by default. Setting this also drops the start-from-now default bound, so an otherwise unbounded search reaches back through the whole record; pair it with date_start_from and date_start_to to study a specific period.", + "type": "boolean" +} - changed
Output schema / properties / appliedFilters / properties / dateStartFrom / descriptionPrevious value: -"Training start date lower bound applied — the caller-supplied value, or the current timestamp when neither date bound was given."New value: +"Training start date lower bound applied — the caller-supplied value, or the current timestamp when neither date bound was given and include_archived was off." - added
Output schema / properties / appliedFilters / properties / presetAdded value: +{ + "description": "ReliefWeb preset the query used: latest (current listings only, default) or analysis when include_archived.", + "type": "string" +} - changed
Output schema / properties / appliedFilters / requiredPrevious value: -[ - "sort", - "limit", - "offset" -]New value: +[ + "sort", + "preset", + "limit", + "offset" +]
6 tool updates
- Changed
reliefweb_list_countries1 field changed- changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when results are empty — echoes the active filter and suggests how to broaden. Absent on successful result pages."New value: +"Present 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."
- Changed
reliefweb_list_sources1 field changed- changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when results are empty — echoes the active filters and suggests how to broaden. Absent on successful result pages."New value: +"Present 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."
- Changed
reliefweb_search_disasters7 fields changed- added
Input schema / properties / date_from / anyOfAdded value: +[ + { + "const": "", + "type": "string" + }, + { + "description": "Calendar date (2024-01-15) or full ISO 8601 datetime (2024-01-15T00:00:00+00:00).", + "pattern": "^\\d{4}-\\d{2}-\\d{2}(?:T\\d{2}:\\d{2}(?::\\d{2}(?:\\.\\d+)?)?(?:Z|[+-]\\d{2}:?\\d{2})?)?$", + "type": "string" + } +] - changed
Input schema / properties / date_from / descriptionPrevious value: -"Earliest disaster creation date (ISO 8601). Filters on date.created."New value: +"Earliest disaster creation date. Filters on date.created. A bare calendar date such as 2024-01-15 is accepted and resolves to start of that day in UTC; a datetime carrying any offset is resolved to UTC." - removed
Input schema / properties / date_from / typeRemoved value: -"string" - added
Input schema / properties / date_to / anyOfAdded value: +[ + { + "const": "", + "type": "string" + }, + { + "description": "Calendar date (2024-01-31) or full ISO 8601 datetime (2024-01-31T23:59:59+00:00).", + "pattern": "^\\d{4}-\\d{2}-\\d{2}(?:T\\d{2}:\\d{2}(?::\\d{2}(?:\\.\\d+)?)?(?:Z|[+-]\\d{2}:?\\d{2})?)?$", + "type": "string" + } +] - changed
Input schema / properties / date_to / descriptionPrevious value: -"Latest disaster creation date (ISO 8601). Pair with date_from for a date range."New value: +"Latest disaster creation date. Pair with date_from for a date range. A bare calendar date resolves to end of that day in UTC, so the range covers it in full; a datetime carrying any offset is resolved to UTC." - removed
Input schema / properties / date_to / typeRemoved value: -"string" - changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when results are empty — echoes filters applied and suggests how to broaden."New value: +"Present 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."
- Changed
reliefweb_search_jobs1 field changed- changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when results are empty — echoes filters applied and suggests how to broaden."New value: +"Present 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."
- Changed
reliefweb_search_reports7 fields changed- added
Input schema / properties / date_from / anyOfAdded value: +[ + { + "const": "", + "type": "string" + }, + { + "description": "Calendar date (2024-01-15) or full ISO 8601 datetime (2024-01-15T00:00:00+00:00).", + "pattern": "^\\d{4}-\\d{2}-\\d{2}(?:T\\d{2}:\\d{2}(?::\\d{2}(?:\\.\\d+)?)?(?:Z|[+-]\\d{2}:?\\d{2})?)?$", + "type": "string" + } +] - changed
Input schema / properties / date_from / descriptionPrevious value: -"Earliest publication date (ISO 8601, e.g., 2024-01-15T00:00:00+00:00). Filters on date.original (source publication date)."New value: +"Earliest publication date. Filters on date.original (source publication date). A bare calendar date such as 2024-01-15 is accepted and resolves to start of that day in UTC; a datetime carrying any offset is resolved to UTC." - removed
Input schema / properties / date_from / typeRemoved value: -"string" - added
Input schema / properties / date_to / anyOfAdded value: +[ + { + "const": "", + "type": "string" + }, + { + "description": "Calendar date (2024-01-31) or full ISO 8601 datetime (2024-01-31T23:59:59+00:00).", + "pattern": "^\\d{4}-\\d{2}-\\d{2}(?:T\\d{2}:\\d{2}(?::\\d{2}(?:\\.\\d+)?)?(?:Z|[+-]\\d{2}:?\\d{2})?)?$", + "type": "string" + } +] - changed
Input schema / properties / date_to / descriptionPrevious value: -"Latest publication date (ISO 8601). Pair with date_from for a date range."New value: +"Latest publication date. Pair with date_from for a date range. A bare calendar date resolves to end of that day in UTC, so the range covers it in full; a datetime carrying any offset is resolved to UTC." - removed
Input schema / properties / date_to / typeRemoved value: -"string" - changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when results are empty — echoes the filters applied and suggests how to broaden. Absent on successful result pages."New value: +"Present 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."
- Changed
reliefweb_search_training8 fields changed- added
Input schema / properties / date_start_from / anyOfAdded value: +[ + { + "const": "", + "type": "string" + }, + { + "description": "Calendar date (2024-06-01) or full ISO 8601 datetime (2024-06-01T00:00:00+00:00).", + "pattern": "^\\d{4}-\\d{2}-\\d{2}(?:T\\d{2}:\\d{2}(?::\\d{2}(?:\\.\\d+)?)?(?:Z|[+-]\\d{2}:?\\d{2})?)?$", + "type": "string" + } +] - changed
Input schema / properties / date_start_from / descriptionPrevious value: -"Training start date lower bound (ISO 8601). Filters on date.start — use to find training starting after a given date."New value: +"Training start date lower bound. Filters on date.start — use to find training starting after a given date. A bare calendar date resolves to start of that day in UTC, and a datetime carrying any offset is resolved to UTC. Omit this and date_start_to together to default the search to training starting from now." - removed
Input schema / properties / date_start_from / typeRemoved value: -"string" - added
Input schema / properties / date_start_to / anyOfAdded value: +[ + { + "const": "", + "type": "string" + }, + { + "description": "Calendar date (2024-12-31) or full ISO 8601 datetime (2024-12-31T23:59:59+00:00).", + "pattern": "^\\d{4}-\\d{2}-\\d{2}(?:T\\d{2}:\\d{2}(?::\\d{2}(?:\\.\\d+)?)?(?:Z|[+-]\\d{2}:?\\d{2})?)?$", + "type": "string" + } +] - changed
Input schema / properties / date_start_to / descriptionPrevious value: -"Training start date upper bound (ISO 8601). Filters on date.start — pair with date_start_from for a window."New value: +"Training start date upper bound. Filters on date.start — pair with date_start_from for a window. A bare calendar date resolves to end of that day in UTC, and a datetime carrying any offset is resolved to UTC. Supplying this alone searches everything up to it, with no lower bound injected." - removed
Input schema / properties / date_start_to / typeRemoved value: -"string" - changed
Output schema / properties / appliedFilters / properties / dateStartFrom / descriptionPrevious value: -"Training start date lower bound applied."New value: +"Training start date lower bound applied — the caller-supplied value, or the current timestamp when neither date bound was given." - changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when results are empty — echoes filters applied and suggests how to broaden."New value: +"Present 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."
4 tool updates
- Changed
reliefweb_get_country3 fields changed- changed
Output schema / properties / appealsResponsePlans / descriptionPrevious value: -"Active humanitarian appeals and response plans for this country."New value: +"Currently-active humanitarian appeals and response plans for this country — the present set, not the full historical archive." - changed
Output schema / properties / keyContent / descriptionPrevious value: -"Curated key content links maintained by ReliefWeb editors."New value: +"Currently-active curated key content links maintained by ReliefWeb editors — the present curated set, not the full historical archive." - changed
Output schema / properties / usefulLinks / descriptionPrevious value: -"Useful external links curated by ReliefWeb editors."New value: +"Currently-active useful external links curated by ReliefWeb editors — the present set, not the full historical archive."
- Changed
reliefweb_get_disaster3 fields changed- changed
Output schema / properties / appealsResponsePlans / descriptionPrevious value: -"Active appeals and response plans linked to this disaster."New value: +"Currently-active appeals and response plans linked to this disaster — the present set, not the full historical archive." - changed
Output schema / properties / keyContent / descriptionPrevious value: -"Curated key content links from the ReliefWeb editorial team."New value: +"Currently-active curated key content links from the ReliefWeb editorial team — the present curated set, not the full historical archive." - changed
Output schema / properties / usefulLinks / descriptionPrevious value: -"Useful external links curated by ReliefWeb editors."New value: +"Currently-active useful external links curated by ReliefWeb editors — the present set, not the full historical archive."
- Changed
reliefweb_search_jobs1 field changed- added
Input schema / properties / sortAdded value: +{ + "description": "Sort order. Use date.created:desc for newest postings first (default), date.closing:asc to surface roles closing soonest, or score:desc for relevance.", + "type": "string" +}
- Changed
reliefweb_search_training1 field changed- added
Input schema / properties / sortAdded value: +{ + "description": "Sort order. Use date.start:asc for soonest-starting training first (default), date.start:desc for latest-starting, date.created:desc for most recently posted, or score:desc for relevance.", + "type": "string" +}
4 tool updates
- Changed
reliefweb_list_countries2 fields changed- changed
Input schema / properties / crisis_only / descriptionPrevious value: -"When true, filters to countries with an active humanitarian situation (status alert or current). Default false returns all countries."New value: +"When true, filters to countries with an active humanitarian situation (status ongoing). Default false returns all countries." - changed
Output schema / properties / items / items / properties / status / descriptionPrevious value: -"Humanitarian situation status. Active situations have status alert or current."New value: +"Humanitarian situation status: ongoing (active crisis) or normal (non-crisis)."
- Changed
reliefweb_list_sources2 fields changed- changed
Input schema / properties / type / descriptionPrevious value: -"Organization type. Must match exact API values: \"Government\", \"International Organization\", \"Non-governmental Organization\", \"Academia\", \"United Nations\", \"Other\". Filters on type.name."New value: +"Organization type. One of: Non-governmental Organization, International Organization, Academic and Research Institution, Other, Government, Media, Red Cross/Red Crescent Movement. Filters on type.name." - added
Input schema / properties / type / enumAdded value: +[ + "Non-governmental Organization", + "International Organization", + "Academic and Research Institution", + "Other", + "Government", + "Media", + "Red Cross/Red Crescent Movement" +]
- Changed
reliefweb_search_disasters1 field changed- changed
Input schema / properties / country / descriptionPrevious value: -"ISO 3166-1 alpha-3 country code (e.g., SYR, AFG, UKR). Filters to disasters tagged with this primary country."New value: +"ISO 3166-1 alpha-3 country code (e.g., SYR, AFG, UKR). Filters to disasters tagged with this country."
- Changed
reliefweb_search_training2 fields changed- changed
Input schema / properties / format / descriptionPrevious value: -"Training format (e.g., Workshop, E-learning, Conference, Seminar). Filters on format.name."New value: +"Training format. Valid values: on-site, online. Filters on format.name." - added
Input schema / properties / format / enumAdded value: +[ + "on-site", + "online" +]
6 tool updates
- Changed
reliefweb_list_countries1 field changed- added
Output schema / properties / noticeAdded value: +{ + "description": "Recovery hint when results are empty — echoes the active filter and suggests how to broaden. Absent on successful result pages.", + "type": "string" +}
- Changed
reliefweb_list_sources1 field changed- added
Output schema / properties / noticeAdded value: +{ + "description": "Recovery hint when results are empty — echoes the active filters and suggests how to broaden. Absent on successful result pages.", + "type": "string" +}
- Changed
reliefweb_search_disasters2 fields changed- added
Output schema / properties / appliedFiltersAdded value: +{ + "additionalProperties": false, + "description": "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.", + "properties": { + "country": { + "description": "Country code as normalized (uppercased ISO3).", + "type": "string" + }, + "dateFrom": { + "description": "Earliest creation date filter applied.", + "type": "string" + }, + "dateTo": { + "description": "Latest creation date filter applied.", + "type": "string" + }, + "disasterType": { + "description": "Disaster type name filter applied.", + "type": "string" + }, + "glide": { + "description": "GLIDE number filter applied.", + "type": "string" + }, + "limit": { + "description": "Result limit the query used.", + "type": "number" + }, + "offset": { + "description": "Pagination offset the query used.", + "type": "number" + }, + "preset": { + "description": "ReliefWeb preset the query used: latest (default) or analysis when include_archived.", + "type": "string" + }, + "sort": { + "description": "Sort order the query used (resolved, including the default).", + "type": "string" + }, + "status": { + "description": "Status filter applied (comma-joined when multiple).", + "type": "string" + }, + "text": { + "description": "Full-text query the search used.", + "type": "string" + } + }, + "required": [ + "sort", + "preset", + "limit", + "offset" + ], + "type": "object" +} - changed
Output schema / requiredPrevious value: -[ - "items", - "totalCount" -]New value: +[ + "items", + "appliedFilters", + "totalCount" +]
- Changed
reliefweb_search_jobs2 fields changed- added
Output schema / properties / appliedFiltersAdded value: +{ + "additionalProperties": false, + "description": "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.", + "properties": { + "careerCategory": { + "description": "Career category name filter applied.", + "type": "string" + }, + "country": { + "description": "Country code as normalized (uppercased ISO3).", + "type": "string" + }, + "experience": { + "description": "Experience level filter applied.", + "type": "string" + }, + "limit": { + "description": "Result limit the query used.", + "type": "number" + }, + "offset": { + "description": "Pagination offset the query used.", + "type": "number" + }, + "sort": { + "description": "Sort order the query used (resolved, including the default).", + "type": "string" + }, + "source": { + "description": "Source short name filter applied.", + "type": "string" + }, + "text": { + "description": "Full-text query the search used.", + "type": "string" + }, + "theme": { + "description": "Theme name filter applied.", + "type": "string" + } + }, + "required": [ + "sort", + "limit", + "offset" + ], + "type": "object" +} - changed
Output schema / requiredPrevious value: -[ - "items", - "totalCount" -]New value: +[ + "items", + "appliedFilters", + "totalCount" +]
- Changed
reliefweb_search_reports2 fields changed- added
Output schema / properties / appliedFiltersAdded value: +{ + "additionalProperties": false, + "description": "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.", + "properties": { + "country": { + "description": "Country code as normalized (uppercased ISO3).", + "type": "string" + }, + "dateFrom": { + "description": "Earliest publication date filter applied.", + "type": "string" + }, + "dateTo": { + "description": "Latest publication date filter applied.", + "type": "string" + }, + "disasterId": { + "description": "Disaster ID filter applied.", + "type": "number" + }, + "format": { + "description": "Format name filter applied.", + "type": "string" + }, + "language": { + "description": "Language code filter applied.", + "type": "string" + }, + "limit": { + "description": "Result limit the query used.", + "type": "number" + }, + "offset": { + "description": "Pagination offset the query used.", + "type": "number" + }, + "preset": { + "description": "ReliefWeb preset the query used: latest (default) or analysis when include_archived.", + "type": "string" + }, + "rawFilter": { + "description": "True when a raw compound filter object was merged into the query.", + "type": "boolean" + }, + "sort": { + "description": "Sort order the query used (resolved, including the default).", + "type": "string" + }, + "source": { + "description": "Source short name filter applied.", + "type": "string" + }, + "text": { + "description": "Full-text query the search used.", + "type": "string" + }, + "theme": { + "description": "Theme name filter applied.", + "type": "string" + } + }, + "required": [ + "sort", + "preset", + "limit", + "offset" + ], + "type": "object" +} - changed
Output schema / requiredPrevious value: -[ - "items", - "totalCount" -]New value: +[ + "items", + "appliedFilters", + "totalCount" +]
- Changed
reliefweb_search_training2 fields changed- added
Output schema / properties / appliedFiltersAdded value: +{ + "additionalProperties": false, + "description": "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.", + "properties": { + "careerCategory": { + "description": "Career category name filter applied.", + "type": "string" + }, + "country": { + "description": "Country code as normalized (uppercased ISO3).", + "type": "string" + }, + "dateStartFrom": { + "description": "Training start date lower bound applied.", + "type": "string" + }, + "dateStartTo": { + "description": "Training start date upper bound applied.", + "type": "string" + }, + "format": { + "description": "Training format name filter applied.", + "type": "string" + }, + "language": { + "description": "Language code filter applied.", + "type": "string" + }, + "limit": { + "description": "Result limit the query used.", + "type": "number" + }, + "offset": { + "description": "Pagination offset the query used.", + "type": "number" + }, + "sort": { + "description": "Sort order the query used (resolved, including the default).", + "type": "string" + }, + "source": { + "description": "Source short name filter applied.", + "type": "string" + }, + "text": { + "description": "Full-text query the search used.", + "type": "string" + } + }, + "required": [ + "sort", + "limit", + "offset" + ], + "type": "object" +} - changed
Output schema / requiredPrevious value: -[ - "items", - "totalCount" -]New value: +[ + "items", + "appliedFilters", + "totalCount" +]
1 tool update
- Changed
reliefweb_list_sources1 field changed- changed
Input schema / properties / type / descriptionPrevious value: -"Organization type (e.g., Government, International Organization, NGO, Academia). Filters on type.name."New value: +"Organization type. Must match exact API values: \"Government\", \"International Organization\", \"Non-governmental Organization\", \"Academia\", \"United Nations\", \"Other\". Filters on type.name."
6 tool updates
- Changed
reliefweb_list_countries1 field changed- changed
Input schema / properties / offset / descriptionPrevious value: -"Zero-based offset for pagination. Use with limit and totalCount to page through results."New value: +"Zero-based offset for pagination. Use with limit and the totalCount enrichment field to page through results."
- Changed
reliefweb_list_sources1 field changed- changed
Input schema / properties / offset / descriptionPrevious value: -"Zero-based offset for pagination. Use with limit and totalCount to page through results."New value: +"Zero-based offset for pagination. Use with limit and the totalCount enrichment field to page through results."
- Changed
reliefweb_search_disasters3 fields changed- changed
Input schema / properties / offset / descriptionPrevious value: -"Zero-based offset for pagination. Use with limit and totalCount to page through results."New value: +"Zero-based offset for pagination. Use with limit and the totalCount enrichment field to page through results." - removed
Output schema / properties / messageRemoved value: -{ - "description": "Recovery hint when results are empty — echoes filters applied and suggests how to broaden.", - "type": "string" -} - added
Output schema / properties / noticeAdded value: +{ + "description": "Recovery hint when results are empty — echoes filters applied and suggests how to broaden.", + "type": "string" +}
- Changed
reliefweb_search_jobs3 fields changed- changed
Input schema / properties / offset / descriptionPrevious value: -"Zero-based offset for pagination. Use with limit and totalCount to page through results."New value: +"Zero-based offset for pagination. Use with limit and the totalCount enrichment field to page through results." - removed
Output schema / properties / messageRemoved value: -{ - "description": "Recovery hint when results are empty — echoes filters applied and suggests how to broaden.", - "type": "string" -} - added
Output schema / properties / noticeAdded value: +{ + "description": "Recovery hint when results are empty — echoes filters applied and suggests how to broaden.", + "type": "string" +}
- Changed
reliefweb_search_reports3 fields changed- changed
Input schema / properties / offset / descriptionPrevious value: -"Zero-based offset for pagination. Use with limit and totalCount from the response to page through large result sets."New value: +"Zero-based offset for pagination. Use with limit and the totalCount enrichment field to page through large result sets." - removed
Output schema / properties / messageRemoved value: -{ - "description": "Recovery hint when results are empty — echoes the filters applied and suggests how to broaden. Absent on successful result pages.", - "type": "string" -} - added
Output schema / properties / noticeAdded value: +{ + "description": "Recovery hint when results are empty — echoes the filters applied and suggests how to broaden. Absent on successful result pages.", + "type": "string" +}
- Changed
reliefweb_search_training3 fields changed- changed
Input schema / properties / offset / descriptionPrevious value: -"Zero-based offset for pagination. Use with limit and totalCount to page through results."New value: +"Zero-based offset for pagination. Use with limit and the totalCount enrichment field to page through results." - removed
Output schema / properties / messageRemoved value: -{ - "description": "Recovery hint when results are empty — echoes filters applied and suggests how to broaden.", - "type": "string" -} - added
Output schema / properties / noticeAdded value: +{ + "description": "Recovery hint when results are empty — echoes filters applied and suggests how to broaden.", + "type": "string" +}
9 tool updates
- First observed
reliefweb_get_country - First observed
reliefweb_get_disaster - First observed
reliefweb_get_report - First observed
reliefweb_list_countries - First observed
reliefweb_list_sources - First observed
reliefweb_search_disasters - First observed
reliefweb_search_jobs - First observed
reliefweb_search_reports - First observed
reliefweb_search_training
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Related MCP Connectors
Search events, conference weeks, cities, venues and artist schedules via remote MCP.
Search FDIC institutions, branches, failures, and peer analysis over MCP.
Search GBIF species taxonomy, occurrence records, datasets, and publishers.
Search GBIF species taxonomy, occurrence records, datasets, and publishers.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceSearch GBIF species taxonomy, occurrence records, datasets, and publishers via MCP.2821Apache 2.0
- AlicenseNot gradedqualityAmaintenanceSearch and query government open-data portals (Socrata SODA API) via MCP.1443Apache 2.0
- AlicenseNot gradedqualityAmaintenanceSearch and analyze global news coverage and US television transcripts via the GDELT Project's real-time APIs via MCP.2034Apache 2.0
- AlicenseNot gradedqualityAmaintenanceSearch USGS and EMSC seismic data for real-time feeds, event queries, and earthquake counts via MCP.2961Apache 2.0
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
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.
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.
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.
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.