Malja MCP

Official

by marsaplatform

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Trend analysis

trend_analysis

Read-only

Analyze how a country’s displacement metric changes over time, including yearly series, year-over-year shifts, linear trend, CAGR, anomalous years, and structural changepoints.

Instructions

Analyse how a displacement metric evolved for a country: yearly series, year-over-year changes, linear trend (slope, R²), CAGR, statistically anomalous years (z-scores of yearly changes) and changepoints (structural breaks in level/slope, exact penalised segmentation). Default: refugees hosted, last 10 years — widen year_from for better changepoint power.

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

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.
`metric`	No	Metric: refugees, asylum_seekers, idps, stateless... (default refugees)
`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
`trend`	Yes
`metric`	Yes
`series`	Yes
`source`	Yes
`country`	Yes
`segments`	Yes
`anomalies`	Yes
`changepoints`	Yes
`country_code`	Yes
`year_over_year`	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

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, and the description adds real substance: the statistical method (exact penalised segmentation), the anomaly basis (z-scores of yearly changes), and the default window. It does not disclose data source, coverage limits, or failure behavior for sparse series, keeping it below a 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?

A single dense sentence that front-loads the output inventory and saves the tuning advice for last; nearly every clause earns its place. It is packed tightly enough that it reads as a list rather than prose, which is a minor cost but not wasteful.

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 annotations covering the safety profile, the description only needs to explain scope, defaults, and method — all of which it does. The remaining gap is routing: it doesn't state how this differs from 'forecast' or 'monitor_changes' for an agent choosing among similar analytical tools.

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, but the description adds meaning the schema lacks: the default metric is refugees, the default window is the last 10 years, and year_from has a documented effect (wider range improves changepoint power). That is genuine parameter-level guidance beyond the field descriptions.

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 ('Analyse how a displacement metric evolved') plus the resource (a country's yearly series) and enumerates the exact computations produced: YoY changes, slope/R², CAGR, z-score anomalies, changepoints. This is clearly distinguishable from siblings like forecast (prediction) or compare_countries (cross-country).

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 a concrete default scope ('refugees hosted, last 10 years') and actionable guidance ('widen year_from for better changepoint power'), which tells an agent how to tune the call. It stops short of explicitly naming when to prefer 'forecast' or 'country_profile' instead, so no exclusion guidance.

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