reliefweb-mcp-server

Get ReliefWeb Job

reliefweb_get_job

Read-onlyIdempotent

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.

Input Schema

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. Records are sparse, so a name this record does not carry is rejected with the names it does. 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 (Markdown) — 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 (Markdown) 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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 26, 2026

changedOutput schema / properties / body / description

Previous value: -"Full vacancy description (HTML) — duties, requirements, and conditions."New value: +"Full vacancy description (Markdown) — duties, requirements, and conditions."

changedOutput schema / properties / howToApply / description

Previous value: -"Application instructions (HTML) as published by the hiring organization."New value: +"Application instructions (Markdown) as published by the hiring organization."

Changed1 schema field changedOct 9, 2026

changedInput schema / properties / sections / description

Previous value: -"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."New value: +"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. Records are sparse, so a name this record does not carry is rejected with the names it does. 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."

Changed6 schema fields changedAug 25, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "kind"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added 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"
+}

removedOutput schema / required
```
Removed value: -[
-  "kind"
-]
```

AddedAug 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, open world), and the description adds genuinely non-obvious behavior: a record exceeding the response budget returns a section outline with per-section byte sizes, the retry path is a re-call with sections, and 'nothing is truncated on either path' reassures the agent no silent data loss occurs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five sentences, front-loaded with purpose and the sibling routing before the outline mechanics. Efficient overall, though the last three sentences restate the outline/sections behavior that the schema already documents at length, so there is some redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description still covers the one thing an agent must anticipate operationally — the over-budget outline response and how to recover from it. With full schema coverage and clear annotations, nothing needed to invoke this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and the description still adds workflow meaning: sections is tied to the outline response's section names and the two-pass fetch pattern, and it notes identity metadata is always returned regardless of requested sections. Minor duplication with the schema's own lengthy sections description keeps it just below 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Fetch a job posting by ReliefWeb numeric ID') and enumerates what the payload contains: full vacancy description, application instructions, dates, organization, location and taxonomy metadata. This is clearly distinguishable from reliefweb_search_jobs, which is named as returning only summaries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: 'Use after reliefweb_search_jobs, which returns summaries without the description or application instructions.' It also states a usage-relevant fact that search tools would not surface — expired postings are reachable — and explains when to re-call with the sections parameter.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All reliefweb-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.