Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@bcrp-mcp ¿Cuál fue la inflación de Lima a 12 meses en setiembre de 2026?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Servidor MCP hecho con FastMCP 4 que le da a Claude acceso a las 17,167 series estadísticas del Banco Central de Reserva del Perú (BCRP) y, para el contexto regional, a los indicadores del Banco Mundial. Las cuentas las hace Python, no el modelo: cada cifra sale de una llamada que se puede repetir y viene con la URL de su fuente.
Tarea de la sesión 04 del curso Data Science con Python
(el enunciado original está en ENUNCIADO.md). Los resultados están en informe.md.
Tipo | Nombre | Qué hace |
Herramienta |
| Busca códigos de serie por palabras en el catálogo del BCRP |
Herramienta |
| Descarga los datos de una serie (diaria, mensual, trimestral o anual) con la URL de la fuente |
Herramienta |
| Primero, último, cambio, variación %, promedio, máximo y mínimo, para que el modelo no calcule a mano |
Herramienta |
| Herramienta propia. Compara al Perú con otros países en PBI, inflación, desempleo, PBI per cápita, exportaciones o deuda, con la API del Banco Mundial |
Recurso |
| La ficha de una serie: nombre, categoría, frecuencia, inicio y última actualización |
Prompt |
| Pide un informe breve que cite el código y el periodo de cada cifra |
Ninguna de las dos APIs pide clave.
Related MCP server: BCRP MCP Server
Necesitas uv y Claude Code.
git clone https://github.com/LuisGuevaraVega/bcrp-mcp && cd bcrp-mcp
uv run pytest -q # 8 passed; la primera vez baja el catálogo del BCRP (~7 MB) a datos/
claude # aprueba los servidores bcrp y fetch de .mcp.jsonEn Claude Code:
«¿Cuál fue la inflación de Lima a 12 meses en setiembre de 2026?»
«¿Creció el Perú más que Chile y Colombia desde 2015?» (usa comparar_paises)
@bcrp:bcrp://serie/PN01273PM ¿desde cuándo hay datos de esta serie?
/mcp__bcrp__informe exportaciones
Para usarlo en otro proyecto: claude mcp add bcrp -- uv run --directory /ruta/a/bcrp-mcp server.py.
Archivo | Qué es |
| El servidor MCP |
| Las 8 pruebas del curso, sin cambios |
| Los servidores |
| 12 preguntas con la cifra oficial (8 del curso y 4 propias) |
| Hace cada pregunta a Claude ( |
| La corrida con web y la corrida base (memoria contra MCP) |
| Genera |
| El informe de la evaluación |
MIT. Los datos son del BCRP y del Banco Mundial.
Busca series del BCRP por palabras: todas deben aparecer en la categoría, el grupo o el nombre.
Ejemplos: "ipc 12 meses", "tipo de cambio interbancario venta", "reservas internacionales netas", "tasa de referencia", "cobre precio". frecuencia: "Diaria", "Mensual", "Trimestral" o "Anual". Devuelve el código, el nombre completo, la frecuencia y desde cuándo hay datos. Si no hay resultados, prueben con menos palabras.
| Name | Required | Description | Default |
|---|---|---|---|
| texto | Yes | ||
| limite | No | ||
| frecuencia | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds genuinely non-obvious behavior: the AND-matching semantics across category/group/name and the fallback when the result set is empty. It repeats the return fields that the output schema already documents, which is redundant rather than harmful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core matching rule, then examples, then the failure-recovery tip — a sensible order an agent can scan. The five-example list is slightly longer than needed and the sentence restating returned fields duplicates the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search over a large catalog, the description covers query construction, filtering, and empty-result handling, and an output schema exists so return shape need not be spelled out. The only real omissions are the undocumented `limite` parameter and any hint that the returned code should be fed to the sibling `serie`.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description has to carry the load and largely does: it explains `texto` as an all-words-must-match search and enumerates valid `frecuencia` values that the schema itself declares only as a bare string. The third parameter, `limite` (default 10), is never mentioned, leaving that gap to the schema's default value alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource ("Busca series del BCRP") and even specifies the matching rule — all words must appear in category, group, or name — which is far more precise than the title alone. It never distinguishes itself from the sibling `serie` (singular), so an agent gets no explicit routing signal about which of the two to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives five concrete query examples and the accepted frequency values, plus an explicit recovery strategy ("Si no hay resultados, prueben con menos palabras"), which tells the agent how to retry rather than guess. It stops short of stating when NOT to use this tool or naming `serie` / `resumen` as the alternative once a code is known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compara al Perú con otros países en un indicador anual del Banco Mundial (el BCRP solo tiene datos del Perú).
Úsenla cuando la pregunta compare países o pida contexto regional: "¿creció el Perú más que Chile?", "inflación de la Alianza del Pacífico". indicador: "pbi" (crecimiento real %), "inflacion" (IPC %), "desempleo" (% de la fuerza laboral), "pbi_per_capita" (US$ corrientes), "exportaciones" (% del PBI), "deuda" (deuda del gobierno central, % del PBI), o un código del Banco Mundial como "NY.GDP.MKTP.KD.ZG". paises: códigos ISO3 separados por comas. Devuelve una tabla año por país, el promedio y el ranking del periodo, y la URL de la fuente.
| Name | Required | Description | Default |
|---|---|---|---|
| desde | No | ||
| hasta | No | ||
| paises | No | PER,CHL,COL,MEX,BRA | |
| indicador | No | pbi |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds real value by naming the external data source (World Bank), the return shape (year-by-country table, period average, ranking, source URL), and the indicator semantics per code. Missing only operational details such as rate limits or behavior when a country lacks data for a year.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then the when-to-use trigger and examples, then parameter semantics, then return shape — no filler sentences. The indicator enumeration is long but every listed value prevents an invalid call.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description still summarizes the returned table, average, ranking and source URL, and it explains the data provenance needed to trust the numbers. Nothing an agent needs in order to select and call this tool is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the load and largely does: it enumerates valid 'indicador' values with units and accepts raw World Bank codes, and specifies 'paises' as comma-separated ISO3. 'desde'/'hasta' are only indirectly covered via 'periodo' and the annual framing, leaving their format/range implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('compara al Perú con otros países en un indicador anual del Banco Mundial') and immediately differentiates from the Peru-only data source used by sibling tools ('el BCRP solo tiene datos del Perú'). An agent can distinguish this from serie/buscar_series without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit activation condition: 'Úsenla cuando la pregunta compare países o pida contexto regional', backed by two realistic example queries. It also implies the complement (Peru-only questions go to the BCRP-based siblings), leaving little to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resume una serie del BCRP en un periodo: primer y último valor, cambio, variación %, promedio, máximo y mínimo.
Úsenla siempre que la pregunta pida una variación, un promedio o un extremo, en vez de calcular a mano. Mismas fechas que serie. Ejemplo: resumen("PD04638PD", "2026-01-01", "2026-10-15").
| Name | Required | Description | Default |
|---|---|---|---|
| desde | Yes | ||
| hasta | Yes | ||
| codigo | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint and openWorldHint already establish that this is a safe, external-data read, so the description needn't restate safety. It adds the aggregate outputs it computes, but says nothing about what happens with empty/invalid ranges, unavailable series codes, or return shape (covered by the output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core definition, then the usage rule, then a compact example — no filler. The 'Mismas fechas que serie' fragment is terse to the point of being slightly cryptic without the sibling's docs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description doesn't need to explain return values, and its job is mainly invocation guidance, which the example covers well. What's missing is minor: date-range boundary behavior and how failures on unknown codes surface.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry parameter meaning — and it largely does: the worked example 'resumen("PD04638PD", "2026-01-01", "2026-10-15")' fixes argument order, shows the expected series-code form, and establishes ISO date format. Only the semantics of 'desde'/'hasta' inclusivity is left unstated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Resume') on a specific resource (a BCRP series over a period) and enumerates exactly what the summary contains: first/last value, change, % variation, average, max, min. That enumeration alone separates it from the sibling 'serie' tool, which returns the raw series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Úsenla siempre que la pregunta pida una variación, un promedio o un extremo, en vez de calcular a mano' gives an explicit selection rule, and 'Mismas fechas que serie' points to the related tool for date alignment. It stops short of naming conditions under which to prefer 'serie' or 'buscar_series' instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Descarga los datos de una serie del BCRP entre dos fechas, con la URL de la fuente.
Usen primero buscar_series para conseguir el código. Fechas: "2025-01" para series mensuales, "2026-10-01" para diarias, "2025-T1" para trimestrales y "2025" para anuales (un año suelto también vale). Ejemplo: serie("PN01273PM", "2025-01", "2025-12"). Para variaciones o promedios usen resumen.
| Name | Required | Description | Default |
|---|---|---|---|
| desde | Yes | ||
| hasta | Yes | ||
| codigo | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description is consistent with a safe external data download. It adds useful context such as the source URL inclusion and the prerequisite code lookup, though it does not discuss rate limits, error behavior, or whether date ranges are inclusive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, followed immediately by the prerequisite, date formats, example, and sibling alternative. Every sentence contributes practical invocation guidance without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter read-only data retrieval tool with an output schema, the description supplies the needed prerequisite, date semantics, example, and alternative routing. Return-value details are appropriately left to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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, and it mostly does: it explains that the code should come from buscar_series and gives accepted date formats with a concrete example. Minor gaps remain around exact date-boundary behavior and explicit parameter-name mapping.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: downloads BCRP series data between two dates, including the source URL. It also distinguishes itself from siblings by naming buscar_series for code lookup and resumen for variations/averages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use buscar_series first to get the series code and to use resumen instead for variations or averages. It also gives concrete date-format guidance for monthly, daily, quarterly, and annual series.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0buscar_seriescomparar_paisesresumenserieScored across 4 tools
Each tool targets a distinct step: search for codes (buscar_series), fetch raw time series (serie), compute statistics (resumen), and cross-country comparison (comparar_paises). The descriptions explicitly chain them (use buscar_series first, use resumen for variations), leaving no plausible misselection.
Two tools use verb_noun (buscar_series, comparar_paises) while two are bare nouns (serie, resumen), mixing conventions within a small set. Names are still readable and Spanish-consistent, but the pattern is not predictable from one tool to the next.
Four tools is a lean, well-scoped surface for a single data source, and each tool earns its place in the search→fetch→summarize→compare workflow. It is slightly thin—no bulk multi-series fetch or metadata/category listing—but not a mismatch.
Core lifecycle is covered: discovery, raw retrieval, aggregation, and international context, with clear dead-end avoidance via the search-first hint. Minor gaps remain—no way to fetch multiple BCRP series in one call or list available categories/frequencies directly.
Macro data for AI agents: GDP, inflation, unemployment and more (World Bank, US BLS). No keys.
Macro data for AI agents: GDP, inflation, unemployment and more (World Bank, US BLS). No keys.
Official statistics for AI agents: Eurostat, World Bank, OECD, IMF and WHO data for 150+ countries.
Premium live data from S&P Global, FRED, OECD & more, plus web search, in one call.
