jp-statistics-mcp

get_multiple_series_data

Read-onlyIdempotent

Fetch time-series data for multiple Japanese statistical series (up to 250 codes) from one database and frequency, with resumable retrieval from a start position.

Instructions

Fetch up to 250 codes from one DB and one frequency. Resume from NEXTPOSITION.

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": {
      "database": "<database>",
      "series_codes": "<series_codes>",
      "start_period": "<start_period>",
      "end_period": "<end_period>"
    },
    "name": "get_multiple_series_data"
  }
}

Input Schema

Name	Required	Description	Default
`database`	Yes
`end_period`	Yes
`series_codes`	Yes
`start_period`	Yes
`start_position`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, so safety is covered; the description adds real behavior beyond that by disclosing the 250-code batch ceiling and a pagination/resume mechanism. The 'NEXTPOSITION' token is opaque and does not match the schema's start_position name, so the resumption instruction is harder to act on than it should be.

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 short sentences with the batching constraint front-loaded and no filler. The 'one frequency' clause is the one piece that does not earn its place, since it maps to no parameter and may send an agent looking for an argument that does not exist.

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

Completeness3/5

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

An output schema exists, so return values need no explanation, and the batch cap plus resume hint cover the trickiest parts of invocation. Still missing for a 5-parameter, 0%-coverage tool are the period format expectations and any positioning relative to get_series_data, which an agent needs to choose and call this correctly.

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 description coverage is 0%, so the description must carry parameter meaning; it partially does by explaining the 250-item limit on series_codes and the resume behavior tied to start_position. It says nothing about the database code format or the start_period/end_period formats (YYYY vs YYYYMM per the schema patterns), and the unexplained 'frequency' constraint further muddies the picture.

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 ('Fetch ... codes'), plus scope constraints: a single database and a batch cap of 250. It does not name or contrast with the obvious sibling get_series_data, and it references a 'frequency' restriction that has no corresponding parameter in the schema, which introduces minor confusion about what is actually being filtered.

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

Usage Guidelines2/5

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

There is no when-to-use guidance and no mention of alternatives such as get_series_data for single-code retrieval or search_series for discovery. The only usable hint is the implicit 'up to 250 codes' batching, which an agent must infer as the reason to prefer this tool over the single-series variant.

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

Deploy Server