Malja MCP

Official

by marsaplatform

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Generate map (GeoJSON)

generate_map

Read-only

Creates a GeoJSON FeatureCollection of country centroid points sized by displacement metrics, so you can map asylum-hosted or origin-displaced populations by year.

Instructions

GeoJSON FeatureCollection of country centroid points sized by a displacement metric — drop it into any GeoJSON viewer (geojson.io, Leaflet, Kepler). by="asylum" maps host countries, by="origin" maps origins.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "generate_map"
  }
}

Input Schema

Name	Required	Description
`by`	No	"asylum" = people hosted IN the country; "origin" = people displaced FROM the country
`year`	No	Year (default: latest)
`limit`	No	Top-N countries (default 25)
`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.
`metric`	No	Metric for point properties (default refugees)

Output Schema

Name	Required	Description	Default
`year`	Yes
`metric`	Yes
`geojson`	Yes
`feature_count`	Yes
`skipped_countries`	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 / year / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / geojson / propertyNames
```
Added value: +{
+  "type": "string"
+}
```
First observedv0.7.0Oct 20, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower, and the description adds real value by disclosing the exact return shape (FeatureCollection of centroid points) and what sizing represents. It omits pagination/truncation behavior and how the limit interacts with the map, which would fully close the loop.

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?

Two sentences, front-loaded with the output artifact before the practical hint. It is tight, though the trailing by= clause is redundant with the schema and could have been spent on something the structured fields don't already say.

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, return values need not be detailed, and the description still characterizes the payload usefully. For a read-only generator with five fully documented, all-optional parameters, an agent has enough to call it correctly; only the limit-to-map interaction is unaddressed.

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% and each parameter already carries a rich description including enum meanings, defaults, and bounds. The description's by="asylum"/by="origin" sentence restates what the schema says verbatim rather than adding new meaning, so the baseline 3 applies.

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 the concrete artifact produced — a GeoJSON FeatureCollection of country centroid points sized by a displacement metric — which is more specific than the name alone. It also conveys the format's interoperability intent (geojson.io, Leaflet, Kepler). It does not explicitly contrast itself with generate_chart or other output siblings, so an agent must infer 'map vs chart' from the format description.

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 viewer list tells the agent this is for visual map consumption, but there is no explicit 'use this when you need a geographic visualization instead of generate_chart' or any exclusion. The by= guidance is usage-relevant but duplicates the schema enum.

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