Skip to main content
Glama
kgy0617

Global Economic Statistical MCP

by kgy0617

Get data (validated, with provenance)

get_data
Read-onlyIdempotent

Retrieve validated macroeconomic time series from global sources, with provenance and cross-validation to compare data across institutions.

Instructions

Retrieve a time series in the canonical model, with validation and provenance.

Three ways to ask (use one):
1. Concept: indicator + country (+ source, cycle), e.g. indicator="CPI_YOY", country="US".
   Korea uses ECOS first; other economies OECD, IMF and BIS. If a source has no data, the next one is tried.
2. ECOS table (Korea): stat_code (+ cycle, item_code1..4)
3. SDMX dataflow: source (OECD | IMF | BIS) + dataflow + key + cycle

* validation: country, frequency, unit (and index base), scale, period, missing, duplicate and revision checks (pass/info/warn/fail)
* cross_validate=True: fetch the concept from every source and compare period by period;
  the result is MATCH, DIFFER (documented cause) or UNRESOLVED (unexplained difference)
* dates: "2024", "2024-03", "2024Q1", "2024-03-15" are converted; default window 3 months for daily data, else 2 years
* transform: "yoy" / "pop" % change — value becomes the change and the level is kept
* rebase_period: rebase an index to that period = 100 (e.g. "2020")

Args:
    indicator: concept id or name (see search_statistics(scope="concepts"))
    country: economy, ISO code or EA (required with indicator; with a direct SDMX query it enables the country check)
    source: ECOS | OECD | IMF | BIS
    stat_code: ECOS table code
    cycle: frequency A/S/Q/M/SM/D
    item_code1..4: ECOS item codes
    dataflow: SDMX dataflow (e.g. "OECD.SDD.STES:DSD_STES@DF_FINMARK(4.0)")
    key: SDMX series key (e.g. "USA.M.IRLT.PA._Z._Z._Z._Z.N")
    start_date: start period
    end_date: end period
    recent_years: window when dates are omitted
    transform: "yoy" | "pop" | "none"
    changes_only: only periods where the value changed (default for policy rates)
    rebase_period: index rebase period
    unit_mult: rescale values to 10^unit_mult (e.g. 12 turns a billions (9) series into trillions)
    cross_validate: include cross-validation across institutions
    output_format: "compact" | "csv" | "json" | "sdmx"
    prefer_latest: when ECOS results are truncated, keep the latest periods
    start_count: ECOS first row
    end_count: ECOS last row
    language: "kr" | "en" (ECOS names)

Returns:
    series (periods and values), provenance (source and citation), validation, and optionally cross_validation

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyNo
cycleNo
sourceNo
countryNo
dataflowNo
end_dateNo
languageNokr
end_countNo
indicatorNo
stat_codeNo
transformNo
unit_multNo
item_code1No
item_code2No
item_code3No
item_code4No
start_dateNo
start_countNo
changes_onlyNo
recent_yearsNo
output_formatNocompact
prefer_latestNo
rebase_periodNo
cross_validateNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A5/5.0
Behavior5/5

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

Annotations only declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description goes far beyond this by specifying validation checks (country, frequency, unit, etc.), cross-validation semantics (MATCH/DIFFER/UNRESOLVED), date conversion rules ('2024', '2024-03', '2024Q1'), default windows (3 months daily, 2 years otherwise), transform behavior, rebase semantics, and the prefer_latest truncation behavior. This is rich behavioral context that directly informs agent expectations. No contradiction with 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?

Although long, the description is meticulously organized: a one-line statement, three numbered access patterns, a bullet list of validation/transformation behaviors, an Args list with short explanations, and a Returns section. Every sentence adds functional value and there is no redundant repetition. The critical usage patterns are front-loaded, so an agent can grasp the core quickly without reading the entire parameter list.

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 24 parameters, no output schema, and no parameter descriptions in the schema, the description carries an enormous burden. It meets this by documenting every relevant behavior, the return structure (series, provenance, validation, optional cross_validation), and providing concrete value examples. The three access patterns cover all major invocation routes, making it fully complete for an agent to call correctly without external documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides zero descriptions (0% coverage) and no enums, so the description is the sole source of parameter meaning. It explains each argument with concrete examples and usage notes: indicator and country are required together, source defaults described, stat_code and dataflow formats are exemplified, and flags like cross_validate and prefer_latest are explained. This fully compensates for the schema's silence.

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?

The description opens with a precise statement of purpose: 'Retrieve a time series in the canonical model, with validation and provenance.' It then enumerates three distinct calling conventions (concept, ECOS table, SDMX dataflow), each with concrete field requirements. This clearly distinguishes the tool from siblings like search_statistics (which searches concepts) and get_metadata (which presumably fetches metadata).

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

Usage Guidelines5/5

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

The description provides explicit routing logic: 'Korea uses ECOS first; other economies OECD, IMF and BIS. If a source has no data, the next one is tried.' It also lists validated access patterns and optional cross-validation, giving the agent unambiguous choices for how to invoke the tool. While it doesn't explicitly contrast with siblings, the level of procedural detail (argument combinations, fallback behavior) functions as strong usage guidance.

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