Skip to main content
Glama
Malja MCP

Malja MCP

Official

Durable solutions

durable_solutions
Read-only

Retrieve annual UNHCR refugee returns, resettlement, naturalisation and IDP return flows by country and year, with origin/asylum roles and optional cross-country or population normalization.

Instructions

UNHCR durable solutions per year: refugee returns, resettlement, naturalisation and IDP returns. These are FLOWS during each year (not end-year stocks), so a period total is reported. role "origin" (default) = solutions for people FROM the country (returns home, resettled/naturalised abroad); role "asylum" = refugees who left the country to return home, people resettled TO it, naturalised IN it. Optional other_country cross-filter and normalize_by ("population" → per 1,000 residents of the country).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "country": "<country>"
    },
    "name": "durable_solutions"
  }
}

Input Schema

NameRequiredDescriptionDefault
roleNo"origin" (default) = solutions for people from the country; "asylum" = solutions in / departures from the country as host or resettlement country
localeNoLanguage of the human-readable text output: "en" (default) or "ar" (Modern Standard Arabic, right-to-left). Structured JSON fields, ISO3 codes and dataset ids stay in English either way.
countryYesCountry name or ISO3 code, e.g. "Egypt", "EGY", "syria"
year_toNoLast year of the range (default: latest available)
year_fromNoFirst year of the range (default: 10 years back)
normalize_byNoNormalize values by a denominator: "population" → per 1,000 residents, "gdp" → per US$1bn GDP. Requires the worldbank provider.
other_countryNoOptional second country for the opposite role, e.g. country="Syria", other_country="Lebanon" → Syrians returning from Lebanon

Output Schema

NameRequiredDescriptionDefault
roleYes
unitYes
yearsYes
sourceYes
countryYes
measureYes
year_toYes
year_fromYes
country_codeYes
normalize_byYes
period_totalYes
period_totalsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.8.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedOutput schema / properties / period_totals / $ref
      Removed value: -"#/properties/years/items/properties/metrics"
    • addedOutput schema / properties / period_totals / additionalProperties
      Added value: +false
    • addedOutput schema / properties / period_totals / properties
      Added value: +{
      +  "naturalisation": {
      +    "type": "number"
      +  },
      +  "resettlement": {
      +    "type": "number"
      +  },
      +  "returned_idps": {
      +    "type": "number"
      +  },
      +  "returned_refugees": {
      +    "type": "number"
      +  }
      +}
    • addedOutput schema / properties / period_totals / type
      Added value: +"object"
  2. First observedv0.7.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the description's added value is the flow semantics and the note that a period total is reported — genuinely useful context a caller could not infer. It also discloses the provider dependency for normalization. Minor gaps remain (coverage/sparsity of UNHCR reporting for some countries, what a missing year yields), so 4 not 5.

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?

Front-loaded with the resource and the flow-vs-stock caveat before the role mechanics, so the most important disambiguation lands first. Dense with parentheticals and slightly crowded in the second half, but every sentence carries information and nothing is filler.

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

Completeness4/5

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

With 7 parameters, an output schema, and read-only annotations, the description covers the non-obvious decisions (role direction, flow totals, normalization provider requirement, cross-country filter). Year range and locale are left to well-documented schema entries, which is appropriate. It stops short of saying how incomplete country coverage is handled by this open-world tool.

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; the description earns above that by re-explaining role with worked semantics ("returns home, resettled/naturalised abroad" vs "resettled TO it, naturalised IN it") and by giving a concrete other_country example (Syria + Lebanon → Syrians returning from Lebanon). It matches rather than merely restates the schema's role wording, adding interpretation value.

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?

Names the specific resource (UNHCR durable solutions: refugee returns, resettlement, naturalisation, IDP returns) and immediately clarifies it reports FLOWS per year rather than end-year stocks. That flow-vs-stock distinction is exactly what separates it from portfolio siblings like refugee_population, so an agent can route without opening the 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?

Gives clear operational context for the key decision point: role "origin" (default) covers solutions for people FROM the country, role "asylum" covers people resettled to / naturalised in it, with concrete glosses in parentheses. It also flags the worldbank dependency for normalize_by. It does not explicitly name a sibling alternative or a when-not-to-use case, which keeps it at 4 rather than 5.

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