INEI MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation2/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.1/5 across 9 of 9 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose2/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![INEI-mcp MCP server](https://glama.ai/mcp/servers/JOSETRA44/INEI-mcp/badges/card.svg)](https://glama.ai/mcp/servers/JOSETRA44/INEI-mcp)

Score Badge

Copy to your README.md:

[![INEI-mcp MCP server](https://glama.ai/mcp/servers/JOSETRA44/INEI-mcp/badges/score.svg)](https://glama.ai/mcp/servers/JOSETRA44/INEI-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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