Malja MCP

Official

by marsaplatform

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Asylum decisions

asylum_decisions

Read-only

Retrieve annual asylum application decisions (recognized, complementary protection, rejected, otherwise closed) and recognition rates by country and year; optionally use origin-country role.

Instructions

Decisions on individual asylum applications per year — recognized, complementary protection, rejected, otherwise closed — plus the recognition rate. role "asylum" (default) = decided IN 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": "asylum_decisions"
  }
}

Input Schema

Name	Required	Description
`role`	No	"asylum" = people hosted IN the country; "origin" = people displaced FROM the country
`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)

Output Schema

Name	Required	Description	Default
`role`	Yes
`source`	Yes
`yearly`	Yes
`country`	Yes
`country_code`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.8.0Oct 29, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
First observedv0.7.0Oct 20, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered, and the description adds genuinely new context: what gets returned (recognized, complementary protection, rejected, otherwise closed) and a derived recognition rate. It does not disclose the data source, reporting lag, or how year defaults behave when no data exists, but it goes beyond restating annotations.

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?

Two clauses with zero waste: outcomes and metric first, the default-role caveat last. Nothing is buried and nothing is repeated from the schema.

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?

Five parameters are fully documented and an output schema exists, so return structure needn't be explained. The only real gap is the absence of any guidance on choosing this tool over the adjacent applications/solutions tools, which matters given a dense sibling set.

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 coverage is 100%, so every parameter already carries its own documentation and the baseline is 3. The description adds a small interpretive gloss on role ("decided IN the country"), which sharpens the distinction between decisions and the schema's "hosted IN the country" wording, but adds nothing about year range or locale.

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?

States a specific verb+resource (asylum decisions) and enumerates the outcome categories plus the derived recognition rate, so an agent knows it returns decision outcomes rather than application counts. It doesn't name the sibling it differs from (asylum_applications), leaving the distinction to be inferred.

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

Usage Guidelines3/5

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

Usage is implied rather than stated — the categories and recognition rate signal an analysis of decision outcomes, but there is no explicit when-to-use, when-not-to-use, or pointer to asylum_applications or durable_solutions. The closing note about role 'asylum' being the default is a semantic clarification, not routing guidance.

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