Click on "Install 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., "@INEI MCP Server show me the population of Lima department"
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.
Connects any MCP-compatible AI agent to INEI Estadist — the official statistics platform of Peru's Instituto Nacional de Estadística e Informática (INEI).
Access Census 2017 data, population indicators, geographic profiles, and social statistics for all 25 departments, 196 provinces, and 1,874 districts of Peru — no API key required.
Works with: Claude Desktop · Claude Code · Cursor · VS Code Copilot · Windsurf · any MCP client
# From source (development)
git clone https://github.com/JOSETRA44/inei-mcp.git
cd inei-mcp
uv sync
uv run inei-mcpRelated MCP server: onpe-mcp
Tool | Description |
| List all 25 Peruvian departments with ubigeo codes and IDs |
| List provinces of a department by ccdd code |
| List districts of a province, or search districts by name |
| Search statistical indicators by keyword |
| Get indicator values across geographies |
| Browse the full thematic indicator tree |
| Census 2017 population profile for a region |
| National demographic or social dashboard |
| List official data sources |
Prompt | Description |
| Structured demographic analysis for a department |
| Compare an indicator across Peru's regions |
| Comprehensive Census 2017 analysis |
URI | Contents |
| Complete API reference |
| All 25 department codes and IDs |
| Indicator categories with example IDs |
{
"mcpServers": {
"inei": {
"command": "uv",
"args": ["--directory", "C:\\Users\\USER\\source\\MCPs\\INEI-mcp", "run", "inei-mcp"]
}
}
}All data from INEI Estadist — Peru's official national statistics platform. Primary data: Censos Nacionales 2017 — XII de Población y VII de Vivienda.
MIT — © 2026 JOSETRA44
Browse the INEI thematic indicator tree — all categories and sub-categories.
Returns the hierarchical topic tree with ~1977 entries from the Census 2017 database. Nodes with tipo=1 are categories; tipo=2 are leaf indicators with an id_indicador.
Use id_indicador (only on tipo=2 nodes) with inei_get_indicator_data (requires id_geografia).
Top-level categories include DEMOGRAFICO, SOCIAL, ECONOMICO, VIVIENDA, HOGARES, EDUCACION, SALUD, EMPLEO.
| Name | Required | Description | Default |
|---|---|---|---|
| root_id | No | Filter to children of a specific topic node by id_tema. Omit to get all topics (1977 items — large response). | |
| only_indicators | No | If true, return only leaf indicators (tipo=2) that have an id_indicador. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Discloses return size (~1977 entries), node types (categoria vs indicador), and the significance of id_indicador. Does not mention idempotency, pagination, or authentication needs, but sufficient for a browse tool.
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?
Five sentences, front-loaded with action and result. Each sentence adds distinct value (purpose, structure, usage, example). No redundant or verbose content.
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?
Despite no output schema, description fully explains return structure and chaining to inei_get_indicator_data. All 2 parameters are well-described. Sibling tools are listed, and the description indirectly differentiates by showing this tool is for browsing the tree.
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 100% (baseline 3). Description adds meaning: explains root_id filters by id_tema, only_indicators returns leaf nodes, and clarifies that id_indicador is only on tipo=2 nodes. These details aid agent in correct parameter usage.
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?
The description clearly states it browses the INEI thematic indicator tree, defines hierarchical structure with categories (tipo=1) and leaf indicators (tipo=2), and lists top-level categories. This distinguishes it from sibling tools like inei_get_indicator_data and inei_search_indicators.
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?
Provides guidance on using id_indicador with inei_get_indicator_data and the root_id parameter to filter. Notes that omitting root_id yields a large response. Lacks explicit when-not-to-use or comparison with all siblings, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get national Census 2017 summary dashboard — demographics or social indicators.
demografico: Population totals, age structure, gender breakdown, urban/rural split, population density, age pyramid data.
social: Education (literacy, school attendance), housing (water, electricity, sanitation), health insurance coverage, household composition.
Returns key national figures, charts data, and breakdowns by region.
For specific regional data, use inei_get_geography_profile instead.
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | No | Dashboard type: 'demografico' (population) or 'social' (education, housing, health). | demografico |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the return content (national figures, charts, regional breakdowns) but does not disclose any potential side effects, performance, or limitations. However, for a read-only dashboard tool, this is largely sufficient.
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 concise and well-structured, with bullet points for clarity. It is front-loaded with the core purpose and efficiently provides additional context after that.
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?
Given the simplicity of the tool (single parameter, no output schema), the description covers its functionality, return values, and alternative tool usage completely. No significant gaps.
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?
The schema has 100% description coverage, with a brief description for the 'tipo' parameter. The tool description adds significant value by detailing what each enum value ('demografico' and 'social') includes, such as population totals, age structure, education, housing, etc.
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?
The description clearly states it retrieves a national Census 2017 summary dashboard for demographics or social indicators. It distinguishes from the sibling tool inei_get_geography_profile, which is for regional data.
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?
The description explicitly notes that for specific regional data, the user should use inei_get_geography_profile instead, providing clear guidance on when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the official data sources available in the INEI Estadist platform.
Returns source IDs, names, and descriptions. Sources include:
Censos Nacionales 2017 (Census)
MINSA (Health Ministry)
RENIEC (Civil Registry)
MEF (Economy Ministry)
SEAS (Education indicators)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the burden. It discloses return fields and example sources but does not mention any potential side effects, authentication, or constraints. Adequate for a simple list tool.
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 extremely concise with a clear first sentence stating purpose and a bullet-style list of examples. Every sentence is valuable and efficient.
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?
The description covers what the tool returns (source IDs, names, descriptions) and examples, which is sufficient for a no-parameter data listing tool. However, it does not specify if there is pagination or ordering.
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?
No parameters exist, so schema coverage is complete. The description does not need to add parameter semantics, but it does not add further context beyond the schema.
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?
The description clearly states the tool lists official data sources from the INEI Estadist platform, with concrete examples that distinguish it from sibling tools which deal with topics, departments, or specific data.
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?
No explicit guidance on when to use this tool vs siblings, but the purpose is straightforward and the examples imply it's for listing available sources. A minimal acceptable score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all 25 departments (regions) of Peru with their geography IDs and ubigeo codes.
Returns id_geografia (used in other tools), ubigeo (6-digit code), ccdd (2-digit dept code), and department name.
Use this first to get the id_geografia or ccdd needed by other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description states it returns specific fields and is a list operation, implying read-only. Lacks details on idempotency, safety, or potential side effects, but for a no-parameter list tool, it is adequate.
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?
Concise, three-sentence description with clear structure: purpose, fields, usage advice. No unnecessary words.
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?
Given simplest input schema (no parameters) and no output schema, the description fully covers what the tool returns and how to use it. Context of sibling tools further clarifies its role.
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?
No parameters, baseline 4. Description adds value by explaining the meaning of returned fields (id_geografia used in other tools, ubigeo as 6-digit code), aiding the agent in chaining.
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?
Explicitly states it lists all 25 departments with specific fields (id_geografia, ubigeo, ccdd, name). Clearly differentiates from sibling tools for provinces/districts.
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?
Directly advises 'Use this first' to get id_geografia or ccdd needed by other tools, providing clear when-to-use context. No when-not-to-use, but sufficient for a simple list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all 25 Peruvian departments (province/district data not available via current API).
Note: The INEI Estadist API currently only exposes department-level geography. Use id_geografia from the results with inei_get_geography_profile for census data.
| Name | Required | Description | Default |
|---|---|---|---|
| ccdd | No | Department code (optional filter) | |
| ccpp | No | Province code (not used, API not available) | |
| search | No | Search term (client-side filter on department names) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that province/district data is unavailable and that the 'ccpp' parameter is ignored. However, it lacks details on authentication, rate limits, or output structure beyond mentioning 'id_geografia'.
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?
Two sentences with no waste, but the first sentence is misleading about the tool's actual purpose (departments vs. districts). Conciseness is good, but clarity suffers.
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?
No output schema, and the description does not specify the structure of the returned data beyond mentioning 'id_geografia'. Given the name mismatch and lack of detail for a simple list endpoint, completeness is insufficient.
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 100%, and the description adds minimal extra insight: it repeats that 'ccpp' is unused and 'search' is client-side, which is already in the parameter descriptions. Baseline 3 is appropriate.
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?
The description states it returns departments, not districts, contradicting the tool name. Additionally, there is a sibling tool 'inei_get_departments' which likely serves the same purpose, but no differentiation is provided.
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?
No guidance on when to use this tool vs. the sibling 'inei_get_departments'. The description only suggests a follow-up action but fails to clarify selection criteria among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Census 2017 population profile for a specific Peruvian geography.
Returns key census indicators for a department, province or district: total population, urban/rural breakdown, gender split, working-age population, electoral population, population density, and more.
Provide id_geografia — a 7-digit ID from inei_get_departments or inei_get_provinces.
Common department IDs:
2010000: Amazonas - 2020000: Ancash - 2030000: Apurimac
2040000: Arequipa - 2050000: Ayacucho - 2060000: Cajamarca
2070000: Callao - 2080000: Cusco - 2150000: Lima
2130000: La Libertad - 2140000: Lambayeque - 2200000: Piura
| Name | Required | Description | Default |
|---|---|---|---|
| id_geografia | Yes | Geography ID (7 digits). E.g. 2150000 for Lima, 2080000 for Cusco. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear burden. It outlines what data is returned (key census indicators) but doesn't explicitly state it is read-only or disclose any potential side effects or permissions. Adequate but not fully transparent.
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?
Every sentence serves a purpose; the description is front-loaded with the main action, followed by clear examples and guidance without redundancy. Bullet list for common IDs improves readability.
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?
Given only one parameter and no output schema, the description covers what the tool returns, how to get the input, and common values. Missing explicit mention of hierarchy levels (department/province/district) from the first sentence, but later clarifies. Sufficiently complete.
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 describes the parameter structure, and the description adds value by explaining the ID format, source tools, and providing concrete examples of valid IDs, which enriches the semantic understanding beyond schema.
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?
The description clearly states the specific verb 'Get' and resource 'Census 2017 population profile', and distinguishes this tool from siblings like inei_get_departments by focusing on a single geography profile.
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 tells the user to provide 'id_geografia' from related tools and lists common department IDs, which guides correct usage. Not explicit about when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get census data for a geography, referencing a specific indicator ID.
Requires both id_indicador (from inei_search_indicators) and id_geografia (from inei_get_departments). Returns the full census profile for that geography including population totals, housing, education, and economic indicators.
Note: due to API changes, returns all available census data for the geography rather than a single filtered indicator. Scan seccion1/seccion2 for your indicator.
Common indicator IDs (Census 2017):
516654: Población Total
262215: Población Censada
262218: Población Censada Urbana
262221: Población Censada Rural
| Name | Required | Description | Default |
|---|---|---|---|
| id_geografia | No | Optional geography ID (from inei_get_departments) to filter and compare. E.g. 2150000 for Lima. | |
| id_indicador | Yes | Indicator ID from inei_search_indicators. E.g. 516654 for Población Total. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It reveals important behavioral info: due to API changes, it returns all available census data rather than a filtered indicator, and instructs to scan sections. This adds significant value beyond 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?
The description is front-loaded with purpose and prerequisites, then a note, then common IDs. It is reasonably concise, though the bold structure adds visual clarity. Could be slightly more compact without losing information.
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?
Given no output schema, the description explains returns (census profile with categories) and hints at structure (seccion1/seccion2), but lacks detailed response format or error handling. Adequate but not fully comprehensive for a tool with no 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 coverage is 100% with clear descriptions. The description adds extra context (common indicator IDs and emphasis on requiring both parameters) but contradicts schema by stating id_geografia is required when schema marks it optional. This reduces clarity.
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?
Description clearly states 'Get census data for a geography, referencing a specific indicator ID.' It distinguishes the tool from siblings by emphasizing both indicator and geography IDs are needed, and notes an API change that affects output, adding specificity.
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 lists prerequisites (id_indicador from inei_search_indicators, id_geografia from inei_get_departments), providing context on when to use. However, it does not mention alternatives or when not to use this tool, which would be helpful given sibling tools like inei_get_census_dashboard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all provinces in a Peruvian department.
Provide ccdd (2-digit department code) — e.g. '15' for Lima, '01' for Amazonas.
Get ccdd from inei_get_departments.
Returns province list with id_geografia, ubigeo, nombre, ccdd, ccpp.
| Name | Required | Description | Default |
|---|---|---|---|
| ccdd | Yes | 2-digit department code. E.g. '15' for Lima, '08' for Cusco, '04' for Arequipa. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses return fields (id_geografia, ubigeo, nombre, ccdd, ccpp). Since tool is read-only and simple, additional behavioral details (e.g., empty list handling) are not critical.
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?
Three sentences: purpose, required parameter with example, and return fields. Front-loaded, no redundancy. Every sentence adds value.
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?
Given only 1 required parameter and no output schema, description covers purpose, input, and return fields. Could mention potential empty results or error conditions, but overall adequate for a simple list tool.
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?
Parameter 'ccdd' is fully described in schema with min/max length and examples. Description adds context by showing typical codes ('15' for Lima) and linking to source tool. Schema coverage is 100%, and description adds value beyond schema.
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?
Description clearly states 'List all provinces in a Peruvian department' with specific verb and resource. It requires a department code and provides examples. Sibling tools (inei_get_departments, inei_get_districts) are differentiated by scope.
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 tells user to provide 'ccdd' (2-digit department code) and how to obtain it from inei_get_departments. Could improve by stating when not to use (e.g., for districts) but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search INEI thematic statistical indicators by keyword.
The INEI Estadist database contains indicators from the National Census 2017 and other official surveys. Search by keyword to find indicators on population, education, housing, health, employment, poverty, and more.
Returns indicator ID (id_indicador), name, and hierarchical path (ruta).
Use id_indicador with inei_get_indicator_data to retrieve actual values.
Example searches: 'poblacion', 'educacion', 'vivienda', 'salud', 'empleo', 'pobreza', 'analfabetismo', 'electricidad', 'agua', 'desague'
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1-100). Default: 20. | |
| query | Yes | Keyword to search. E.g. 'poblacion urbana', 'educacion', 'agua potable' | |
| offset | No | Skip first N results for pagination. Default: 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Does not explicitly state it is read-only or non-destructive, but as a search tool this is implied. Could be more transparent about any rate limits or authentication needs.
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?
Reasonably concise with three short paragraphs. First sentence is clear. Could be slightly more concise by removing the list of example searches from the description, but overall well-structured.
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?
Given no output schema and moderate complexity, description adequately covers tool purpose, return values, and relationship to sibling tool. Pagination via offset/limit is explained in schema, not repeated.
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 100%, so baseline is 3. Description adds value by clarifying return fields (id_indicador, name, ruta) and providing usage context beyond schema parameter descriptions.
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?
Clearly states the tool searches INEI thematic indicators by keyword, specifies the database source and indicator types. Distinguishes from sibling tools like inei_browse_topics which likely uses browsing instead of keyword search.
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?
Provides example searches and explains how to use the returned id_indicador with inei_get_indicator_data. Lacks explicit guidance on when not to use this tool, but overall helpful context to guide the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tool set has a major disambiguation problem due to inei_get_districts being misnamed: its description says it returns all 25 departments, not districts, making it redundant with inei_get_departments. Other tools like inei_browse_topics, inei_search_indicators, and inei_get_indicator_data have distinct roles, but the duplication causes confusion.
All tools use the 'inei_' prefix and snake_case, with a consistent verb_noun pattern (get_*, browse_*, search_*). However, inei_get_districts is misleading because it does not return districts but departments, breaking semantic consistency. inei_get_census_dashboard uses 'dashboard' instead of a data-object noun, which is a minor deviation.
With 9 tools, the set is well-scoped for a statistical API covering browsing, searching, geography listing, geography profiling, and data retrieval. Each tool has a clear purpose, and the count feels neither too sparse nor overwhelming.
The set covers the main workflows: explore topics, search indicators, retrieve data by geography, and get national summaries. It can handle department and province queries. However, the duplicate get_districts tool is unnecessary, and the API's limitation to department-level geography (no district data) is a domain constraint. Minor gaps exist (e.g., no hierarchical drill-down beyond two levels), but overall coverage is good for a read-only census API.
INEGI MCP — Mexico's national statistics office (INEGI) Indicators API.
Banco Central de Reserva del Perú (BCRP) statistics series API MCP. Keyless.
Public Data Ukraine Mcp connects AI agents to real public APIs via MCP. Tools include
INE Spain (Instituto Nacional de Estadística) Tempus3 JSON API MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/JOSETRA44/INEI-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server