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

TableJSON 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

TableJSON 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.

Schema Changelog

Changes observed during successful MCP inspections.

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.5/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, but the description adds behavior the annotations do not: expired postings are still reachable, oversized records return a section outline with per-section byte sizes instead of data, and nothing is truncated on either path. That is exactly the extra operational context an agent needs.

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

Conciseness5/5

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

Four sentences, front-loaded with the fetch and its payload, then the routing advice, then the edge-case behavior. Every sentence carries information an agent needs; nothing is filler.

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, so return values need no prose. Between the description's outline/budget behavior and the schema's parameter documentation, an agent has everything required to call and interpret this tool correctly.

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

Parameters3/5

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

Schema description coverage is 100%, and the schema's own text for sections (rejection of unknown names, identity metadata always returned, self-contained re-fetch) is at least as detailed as the description. The description adds only the re-call workflow, so baseline 3 is appropriate.

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 (Fetch) and resource (a job posting by ReliefWeb numeric ID) and enumerates what the record contains: vacancy description, application instructions, dates, hiring organization, location and taxonomy metadata. This lets an agent distinguish it from reliefweb_get_report, reliefweb_get_training and the search siblings without opening any schema.

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

Usage Guidelines4/5

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

Explicitly names the sibling to call first and the condition that selects this tool: "Use after reliefweb_search_jobs, which returns summaries without the description or application instructions." It also notes it reaches expired postings, widening the applicable context. It does not state a when-not case, so it stops short of the full 5.

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.