Skip to main content
Glama
JOSETRA44

BCRP MCP Server

by JOSETRA44
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

bcrp_get_series_long

Fetch up to 50 BCRP economic series at once as a tidy long-format table, even with mixed frequencies. Get series_code, period, date, and value rows, with optional full history.

Instructions

Fetch MANY BCRP series at once as one tidy long-format table.

Unlike bcrp_get_series, the codes do NOT have to share a frequency and the limit is 50 rather than 10 — each series is fetched separately, so the code→value mapping is always correct.

Returns rows of {series_code, period, date, value}. date is an ISO-sortable rendering of BCRP's human period label. Missing observations are omitted rather than emitted as nulls.

Set all_history=true to pull each series' entire published history (bounded by max_rows).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
languageNo'esp' (Spanish) or 'ing' (English)esp
max_rowsNoHard ceiling on returned rows.
end_periodNoEnd of range, same format as start_period.
all_historyNoFetch each series' full published history.
series_codesYes1–50 BCRP series codes; frequencies may be mixed.
start_periodNoStart of range (Daily DD-MM-YYYY, Monthly/Quarterly YYYY-M).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the row schema, the date rendering, that missing observations are omitted rather than null, that each series is fetched separately, and that all_history is bounded by max_rows.

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?

The description is compact, front-loaded with the core purpose, then clearly moves to sibling differentiation, return semantics, and parameter guidance. Every sentence adds needed information and no filler is present.

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?

Even without an output schema, the description specifies the exact returned row fields and their semantics, explains key edge-case behavior, and names the main alternative. Given the schema already documents parameters and formats, this is complete enough for an agent to invoke correctly.

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 description coverage is 100%, so the baseline is 3, and the description adds meaningful extra context: series_codes can mix frequencies up to 50, all_history behavior is bounded by max_rows, and the output mapping is always correct because series are fetched separately. This goes beyond simply restating the schema.

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 specific verb and resource: 'Fetch MANY BCRP series at once as one tidy long-format table.' It also explicitly contrasts itself with bcrp_get_series, so an agent can immediately tell this tool apart from the closest sibling.

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?

It names the alternative bcrp_get_series and gives concrete selection criteria: use this when series codes do not share a frequency or when more than 10 codes are needed. It also provides an explicit trigger for all_history=true and notes the max_rows bound.

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

Deploy Server

Other Tools