mcp-cnes

by kevyn-castelo

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: loading data, retrieving instructions, performing three different types of searches (by municipality, CNES code, or UF), and computing statistics. There is no overlap or ambiguity between these operations.
Naming Consistency4/5
All tools share the 'cnes_' prefix and use lowercase with underscores. Most follow a verb_target pattern (load_data, search_municipio, etc.), though 'cnes_statistics' is a noun rather than a verb, deviating slightly from the pattern.
Tool Count5/5
Six tools is well-suited for a CNES data server covering ingest, guidance, multiple query methods, and statistics. The count feels neither sparse nor bloated, and each tool contributes a necessary function.
Completeness4/5
The server covers the full workflow: loading data, searching by key identifiers (CNES code, municipality, UF), and generating statistics. Minor gaps exist, such as no explicit way to clear or update loaded data, but the atomic load operation and search coverage handle core needs well.
Average 3.7/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 31 commits in the last 12 weeks
- Last stable release on August 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description gives minimal behavioral information: it implies a read-only search operation and the filtering by UF and bed range. However, it does not disclose any additional behavior such as pagination, result limits, or the nature of the response, which would be important given no annotations are provided.
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 a single, concise sentence that directly states the tool's purpose. It has no redundancy, but it is also quite sparse; it could benefit from a bit more detail without becoming verbose.
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 the tool has a comprehensive schema (100% param coverage) and an output schema, the description only needs to convey the core purpose, which it does. However, it lacks any mention of the intended use case relative to sibling tools, making it somewhat incomplete for an AI agent.
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?
The schema descriptions cover all four parameters (100% coverage), so the description adds little semantic value. It does mention the 'faixa opcional de leitos' concept, but the schema already defines min_leitos and max_leitos inclusiveness, so the description adds no new dimension.
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 uses the specific verb 'busca' (searches) and the resource 'estabelecimentos' (establishments), clearly stating the search by UF and optional bed range. This distinguishes it from sibling tools like cnes_search_municipio (different filter) and cnes_search_cnes (search by CNES).
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?
The description provides no guidance on when to use this tool versus the sibling tools. It only states what it does, without mentioning conditions, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Sem anotações, a descrição tem o ônus total de revelar o comportamento. Ela informa que é uma explicação, mas não esclarece se a saída é um texto passo a passo, um link ou outra forma, nem menciona efeitos colaterais ou requisitos. Isso é insuficiente.
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?
A descrição é uma única frase em português, direta e sem redundância. É concisa, transmitindo a finalidade de forma imediata e sem desperdício de palavras.
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?
Considerando a simplicidade (sem parâmetros, com output schema), a descrição é razoavelmente completa para comunicar o propósito. A existência de output schema reduz a necessidade de detalhar retornos, mas a falta de contexto sobre o formato da saída e o momento de uso impede uma nota máxima.
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?
A ferramenta possui zero parâmetros e o schema de entrada é vazio, com cobertura de descrição em 100%. Conforme a regra, com 0 parâmetros a linha de base é 4, e a descrição não precisa compensar detalhes de parâmetros.
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?
A descrição declara especificamente que a ferramenta explica como obter um CSV no dashboard oficial do CNES. O verbo 'explica' e o recurso 'CSV no dashboard' são claros, distinguindo-se das ferramentas irmãs que executam funções de busca ou carga de dados.
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?
Não há orientação sobre quando usar esta ferramenta versus as alternativas. Não menciona que deve ser utilizada para obter instruções manuais de download, nem indica quaisquer exceções. Apenas descreve a função, sem contexto de uso.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of disclosing behavior. It does not state whether the tool is read-only, what happens if no data is loaded, or any potential side effects. The only behavioral hint is the dependency on previously loaded data, which is insufficient for full transparency.
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 a single, focused sentence in Portuguese that conveys the essential purpose without unnecessary words. Every word earns its place, and it is immediately understandable.
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 the tool has no parameters and an output schema exists, the description adequately covers the prerequisites by referencing loaded data. It could be more specific about what statistics are returned, but the output schema likely captures that. The description is sufficiently complete for a simple tool.
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?
The tool has zero parameters, so there is nothing to document in the schema or description. Per the baseline for 0 parameters, a score of 4 is appropriate.
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?
The description clearly identifies the tool's function as returning statistics for currently loaded data. The verb 'Retorna' (returns) and object 'estatísticas' specify the action and resource, and it is distinct from sibling search/load tools. However, the exact nature of the statistics is not elaborated, preventing a perfect score.
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?
The phrase 'dados atualmente carregados' implies the tool should be used after data is loaded, providing a clear precondition for use. It does not explicitly mention alternatives or exclusions, but none are needed for a statistics tool. This gives a clear context, though not fully explicit.
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 are provided, so the description must carry the transparency burden. It discloses the atomicity of the operation ('atomicamente') and the consolidation aspect, which are meaningful behavioral traits. However, it does not describe potential side effects, such as whether data is overwritten or appended, or any permission requirements.
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 a single, concise sentence that clearly states the tool's action and target resource with no unnecessary words. It earns its place and is easy to parse.
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?
This is a simple tool with one parameter and an output schema, so the description does not need to explain return values. It covers the core action and highlights atomicity, which is essential for a data-loading operation. However, a brief note on whether the operation replaces or appends existing data would make it more complete.
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% because the only parameter, 'filepath', has a description. The tool description does not add further parameter semantics beyond what is already in the schema, aligning with the baseline for high schema coverage.
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 uses a specific verb 'Carrega e consolida atomicamente' (loads and atomically consolidates) with a clear resource 'CSV exportado do CNES'. This distinguishes it from sibling tools like cnes_search_municipio and cnes_statistics, which are search/analysis tools rather than load/ingest tools.
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?
The description implies the tool is used for loading CNES CSV data but does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites. The purpose is clear from context, but no direct guidance is provided.
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 are provided, so the description carries the burden. It indicates a read-only search operation via 'busca', but doesn't disclose return format, error handling, or whether multiple results are possible. This is a minimal behavioral disclosure for a simple read 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?
One sentence, front-loaded with the verb and resource. No waste.
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 tool is simple with a single required parameter, and an output schema exists, so the description needn't explain return values. It adequately covers the purpose, but lacks comparative context with sibling search tools, which is a minor gap given its simplicity.
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?
The parameter is fully described in the schema with pattern and explanation, giving 100% coverage. The description adds little beyond restating the seven-digit code, but since schema is complete, the baseline of 3 applies.
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 uses the specific verb 'Busca' (searches) and identifies the resource as an establishment, clearly stating the search key is the seven-digit CNES code. This distinguishes it from sibling tools like cnes_search_municipio and cnes_search_uf, which search by other criteria.
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?
The description implies the tool is used when searching by CNES code, which is clear from the phrase 'pelo código CNES'. However, it doesn't explicitly compare against alternatives or state when to prefer this over the municipality or UF searches, so it lacks explicit when-not guidance.
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?
With no annotations, the description carries the burden of disclosing behavior. It correctly uses the verb 'Busca', implying a read-only search operation, but it does not disclose additional behavioral traits such as result limits, default pagination, or whether the search is case-sensitive. The output schema covers return values, but the description itself adds minimal behavioral context beyond the core action.
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 a single sentence that conveys the essential purpose and scope without any filler. Every word earns its place, and it is appropriately short for a tool whose details are largely in the schema.
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 the output schema and 100% parameter coverage, the description is complete enough for an agent to understand the tool's function. It correctly highlights the main filters (municipality and bed range) and the tool's focus, while the output schema covers return values. The only minor gap is the lack of explicit mention of the 'limit' parameter, but the schema already documents it.
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 100%, so the baseline is 3. The description refers to the key parameters (municipio, min_leitos, max_leitos) through 'município' and 'faixa opcional de leitos', but it does not add any syntax, format, or interaction details beyond what the schema already provides. Therefore, it neither enhances nor detracts from the schema semantics.
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 searches establishments ('estabelecimentos') by municipality ('munícipio') and optional bed range ('faixa opcional de leitos'), using a specific verb 'Busca'. The municipality scope distinguishes it from sibling tools like cnes_search_uf, making the purpose unambiguous.
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?
The phrase 'por município' clearly implies the intended use case for municipality-based searches, providing clear context. However, it does not explicitly exclude other use cases or mention alternatives like cnes_search_uf, so it lacks explicit exclusions but is still clear enough for an agent to infer when to use it.
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:

[![mcp-cnes MCP server](https://glama.ai/mcp/servers/kevyn-castelo/mcp-cnes/badges/card.svg)](https://glama.ai/mcp/servers/kevyn-castelo/mcp-cnes)

Score Badge

Copy to your README.md:

[![mcp-cnes MCP server](https://glama.ai/mcp/servers/kevyn-castelo/mcp-cnes/badges/score.svg)](https://glama.ai/mcp/servers/kevyn-castelo/mcp-cnes)

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/kevyn-castelo/mcp-cnes'

If you have feedback or need assistance with the MCP directory API, please join our Discord server