Malja MCP

Official

by marsaplatform

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Refugee population

refugee_population

Read-only

Retrieve yearly displacement figures for a country—refugees, asylum-seekers, IDPs, stateless people and others—by asylum or origin role, with optional cross-country filtering.

Instructions

Yearly displacement figures for a country: refugees, asylum-seekers, IDPs, stateless and others. role "asylum" (default) = hosted in the country; role "origin" = displaced from it. Optionally cross-filter by a second country (e.g. Syrians hosted in Egypt). Paginated.

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": "refugee_population"
  }
}

Input Schema

Name	Required	Description
`page`	No	1-based page (default 1)
`role`	No	"asylum" = people hosted IN the country; "origin" = people displaced FROM the country
`limit`	No	Rows per page (default 100)
`locale`	No	Language 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.
`country`	Yes	Country name or ISO3 code, e.g. "Egypt", "EGY", "syria"
`year_to`	No	Last year of the range (default: latest available)
`year_from`	No	First year of the range (default: 10 years back)
`other_country`	No	Optional second country for the opposite role, e.g. country="Egypt", role="asylum", other_country="Syria" → Syrians in Egypt

Output Schema

Name	Required	Description	Default
`source`	Yes
`records`	Yes
`page_info`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.8.0Oct 29, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / page / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / records / items / properties / metrics / propertyNames
```
Added value: +{
+  "type": "string"
+}
```
First observedv0.7.0Oct 20, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety/access profile is covered. The description's only behavioral addition is the trailing 'Paginated.', which largely restates the page/limit parameters already documented in the schema; it says nothing about data recency, source, or coverage limits of the underlying displacement series.

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?

Four tight sentences, front-loaded with what the data is, then the role switch, then the cross-filter, then pagination — no filler. The role sentence duplicates the enum description in the schema, which is the only redundancy.

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 an output schema present and complete parameter documentation, the description only needs to establish scope and query combinations, which it does. Minor gap: no mention of the underlying dataset/recency or what happens when a country-year has no displacement figures.

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 every parameter carries an enum or example, so the schema does the heavy lifting. The description reinforces role and other_country with an illustrative pairing, but adds no format or edge-case detail (e.g. ISO3 vs name normalization, behavior when other_country's role is ambiguous) beyond what the schema states.

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

Purpose4/5

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

The description names a specific resource and measurement type — yearly displacement stock figures (refugees, asylum-seekers, IDPs, stateless, others) for one country — which is enough to tell it apart from count/applications tools. It never explicitly contrasts itself with siblings such as asylum_applications, asylum_decisions, or country_profile, so it stops short of full differentiation.

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?

It spells out the two operating modes (role='asylum' hosted vs role='origin' displaced) and the optional cross-filter pattern with a concrete example ('Syrians hosted in Egypt'), which is real usage guidance. It gives no exclusions — nothing says when to prefer asylum_applications or country_profile instead.

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