Malja MCP

Official

by marsaplatform

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Export formatted report (HTML / PDF)

export_report

Read-only

Generate print-ready, self-contained HTML or PDF country reports or formatted markdown outputs with embedded fonts, charts, citations, and extraction manifest.

Instructions

Export a print-ready, self-contained document: the full country report (pass country) or any tool’s markdown output (pass markdown, e.g. from trend_analysis or durable_solutions). format "html" (default) = one file with embedded Arabic/Latin font, inline SVG charts, citations and the extraction manifest; "pdf" = the same rendered by a local headless Chrome/Chromium/Edge (falls back to HTML with an explanation if none is available). Arabic output (locale "ar") is right-to-left. Returns a resource link (export://…) unless inline is true.

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

Input Schema

Name	Required	Description
`title`	No	Document title (markdown mode)
`format`	No	Output format (default html)
`inline`	No	Embed the file in the result instead of returning a resource link (default false)
`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`	No	Country for a full country report (name or ISO3). Omit when passing markdown.
`year_to`	No	Last year of the range (default: latest available)
`markdown`	No	Markdown to format instead of a country report (e.g. a tool’s text output)
`year_from`	No	First year of the range (default: 10 years back)
`include_manifest`	No	Append the extraction manifest (default true)

Output Schema

Name	Required	Description	Default
`uri`	Yes
`bytes`	Yes
`title`	Yes
`format`	Yes
`locale`	Yes
`sha256`	Yes
`filename`	Yes
`manifest`	No
`mime_type`	Yes
`pdf_engine`	No
`fallback_reason`	No
`requested_format`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.8.0Oct 29, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedOutput schema / properties / manifest / propertyNames
```
Added value: +{
+  "type": "string"
+}
```
First observedv0.7.0Oct 20, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses that PDF is produced by a local headless Chrome/Chromium/Edge with a documented HTML fallback if none is present, that HTML is a single self-contained file with embedded fonts, inline SVG and citations, and that the result is a resource link unless `inline` is true. These are exactly the operational facts an agent needs before invoking.

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 front-loaded paragraph that leads with what the document is and the two input modes, then format behavior, then return shape. Dense with parentheticals but nearly every clause carries operational information; a minor trim of the format parenthetical would help.

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

Completeness5/5

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

With 9 optional parameters, an output schema, and annotations in place, the description covers the remaining burdens: input-mode selection, format semantics and fallback, RTL behavior, and the link-vs-inline return contract. Nothing an agent needs to call this correctly is missing.

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 real semantics: `format` defaults to html and what pdf entails, `inline` switches between resource link and embedded file, and `locale: "ar"` yields right-to-left rendering. Only `title`, `year_from`/`year_to` and `include_manifest` are left entirely to the schema.

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 and resource: renders a print-ready self-contained document from either a country report or arbitrary markdown. The two input modes are explicit, which implicitly separates it from content-generating siblings like generate_country_report. It does not, however, contrast itself with export_data, the other export-oriented sibling.

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?

Clear routing rules: pass `country` for a full country report, pass `markdown` for output from trend_analysis or durable_solutions, and default to html. No explicit when-not-to-use or alternative-tool guidance (e.g. when to prefer export_data or generate_country_report) is given.

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