mcp-brasil

Server Quality Checklist

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

Latest release: v0.14.0
Disambiguation3/5
There is noticeable overlap between recomendar_tools, planejar_consulta, and search_tools, as all accept natural language queries and return tool recommendations, albeit in different formats. listar_features and listar_datasets_disponiveis are distinct but share a similar prefix. The remaining tools are clearly separated.
Naming Consistency2/5
Tool names mix Portuguese (listar, recomendar, planejar, executar) and English (search, call), creating an inconsistent impression. Although most follow a verb_noun pattern, the language switch is jarring and not predictable.
Tool Count5/5
Seven tools is well-scoped for a meta-orchestration server. Each tool serves a distinct role in the discovery, planning, and execution workflow without unnecessary redundancy or excessive count.
Completeness4/5
The tool set covers the main workflow: listing features, discovering tools, planning queries, and executing them individually or in batch. Minor gaps exist, such as no direct tool to manage datasets or inspect feature details, but the core surface is functional.
Average 4.2/5 across 7 of 7 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 6 of 17 community issues answered or closed in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on April 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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?
With no annotations provided, the description carries the full burden for behavioral disclosure. It merely restates the schema without describing side effects, return values, error conditions, or the fact that calling arbitrary tools may have destructive consequences. This is a significant transparency gap.
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 exactly two sentences, front-loaded with the primary action and followed by a usage hint. Every word earns its place, with no redundancy or fluff.
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?
The tool is simple, but with no output schema and no annotations, the description could have mentioned that the tool returns the called tool's output or that invalid names will error. The core functionality is clear, but some behavioral expectations are missing, so it is minimally viable rather than 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%, with both parameters described. The description adds little beyond the schema, repeating 'by name with the given arguments' without explaining how arguments map to the called tool's parameters. Baseline 3 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 states the action: 'Call a tool by name with the given arguments,' which specifies the verb and resource. It also differentiates from search_tools by noting the tool is for executing discovered tools, but it does not explicitly distinguish from the sibling executar_lote, so it falls short of a 5.
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 provides clear usage context: 'Use this to execute tools discovered via search_tools.' This tells the agent when the tool is appropriate, but it does not mention exclusions or alternatives, so it is not a full 5.
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?
There are no annotations, so the description carries the full burden. It discloses that the tool uses AI to understand intent and suggests the most adequate tools from mcp-brasil, which implies a non-destructive read-only operation. However, it does not describe the output structure (though an output schema exists) or any limitations of the AI-based recommendation process.
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. It front-loads the core purpose in the first sentence, adds a brief clarifying sentence about the AI mechanism, and then presents the argument documentation in a clean, scannable format. No word is wasted.
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?
For a simple one-parameter recommender, the description adequately covers the main functionality, the input format, and the source of recommendations (mcp-brasil). The presence of an output schema reduces the need to document return values. It could explicitly differentiate from 'search_tools', but overall it is sufficiently complete for an agent to select and invoke it.
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 input schema provides zero description for the single 'query' parameter, but the description compensates with an 'Args' section that explains the parameter meaning and gives a concrete example: 'quero dados sobre gastos do governo federal'. This fully covers the parameter's 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 the tool's purpose: 'Recomenda tools relevantes a partir de uma pergunta em linguagem natural' (Recommends relevant tools from a natural language question). It uses a specific verb ('recomenda') and resource ('tools'), and distinguishes itself from siblings like 'search_tools' by emphasizing AI-based intent comprehension and providing explanations for each recommendation.
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 does not provide any guidance on when to use this tool versus alternatives such as 'search_tools' or 'listar_features'. It mentions that the tool will explain 'quando e como usar cada uma' (when and how to use each recommended tool), but this refers to the output content, not to the circumstances under which an agent should invoke this tool itself.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only mentions parallel execution and the need for full tool names, but does not disclose failure semantics, partial failure behavior, side effects of executing multiple tools, permissions, or result format. This is a significant gap for a batch execution tool that may invoke arbitrary tools with potential side effects.
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 well-structured and front-loaded with the core verb and purpose. Each section (when to use, required format, example) earns its place, and the example improves clarity without excessive verbosity.
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 the essential invocation details and example, and the presence of an output schema reduces the need to explain return values. However, it omits constraints like maximum batch size or behavior on individual tool failures, which are relevant for safe and effective use of a batch execution tool. Overall it is quite complete for typical use.
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 input schema for 'consultas' is essentially opaque (no property descriptions), so the description fully compensates by defining the exact structure of each item (required 'tool' and 'args' keys) and providing a clear example. This adds substantial meaning 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 states 'Executa múltiplas tools em uma única chamada, em paralelo', clearly identifying the verb, resource, and parallel execution mode. It distinguishes itself from siblings like 'call_tool' by emphasizing batch execution of multiple tools in one call.
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?
It explicitly says when to use: 'para evitar chamadas sequenciais quando precisar de dados de várias fontes ou de vários anos/parâmetros ao mesmo tempo'. It does not explicitly name alternatives (e.g., 'call_tool') for single calls, but the usage 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?
With no annotations provided, the description carries the transparency burden. It discloses the tool's scope (all registered, including inactive datasets), that sizes are approximate, and that it reports cache download status. The dependency on MCP_BRASIL_DATASETS is explained. It implicitly indicates a read-only operation via 'lista', though it does not explicitly state this.
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 front-loaded with a clear purpose statement, followed by relevant context about the cache dependency, and ends with a structured return specification. Each sentence adds necessary information without fluff, making it concise and 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?
The description covers the tool's purpose, scope, behavior (active/inactive, approximate size, cache state), and the environment variable dependency. It also specifies the return format in plain text, even though an output schema exists. Slightly more detail on prerequisites or explicit read-only nature would improve completeness, but it is adequate for a no-parameter listing 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 the schema is empty. The description adds meaning by explaining that no input is needed and that the tool simply lists datasets and their cache state. Since there are no parameters, the baseline of 4 applies and the description adequately communicates the lack of inputs.
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 first sentence clearly states the verb and resource: 'Lista os datasets locais (ADR-004) disponíveis e seu estado de cache.' It further distinguishes itself from siblings like 'listar_features' by focusing on datasets and explicitly reporting all registered datasets (active and inactive).
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 usage for checking dataset availability and cache status, noting that features depend on local cache. However, it does not explicitly state when to prefer this tool over alternatives such as 'listar_features', nor does it mention when not to use it.
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, the description carries the full burden. It discloses that results are 'matching tool definitions ranked by relevance' and that the format matches 'list_tools', which are behavioral details. However, it does not mention potential limitations or side effects, but for a read-only search tool this is 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?
Two concise sentences, front-loaded with the core action, and no wasted words. The cross-reference to list_tools is efficient and informative.
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?
The tool is simple with one parameter and has an output schema. The description adequately covers purpose, return format, and ranking, making it complete for the tool's complexity.
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 a single parameter 'query' that has a description. The description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate.
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 'Search for tools using natural language' with a specific verb and resource, and distinguishes itself from sibling tools like recomendar_tools and call_tool by focusing on search. It also clarifies the output is 'matching tool definitions', reinforcing the purpose.
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 for searching tools via natural language, and the phrase 'ranked by relevance' gives context on expected results. It does not explicitly exclude alternatives or say 'use this when', but the context is clear enough for a search tool.
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, the description carries the full burden of disclosing behavior. It clearly indicates a read-only listing action and describes the returned content ('Resumo das features ativas com descrição e status de autenticação'), which is sufficient for a simple, non-mutating tool. It does not mention side effects because there are none.
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 a clear opening statement, an explicit usage sentence, and a separate 'Returns:' section. Every sentence contributes useful information, and there is no waste.
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?
For a tool with no parameters and a simple listing function, the description is complete. It explains what is listed, why to use it, and what is returned. The presence of an output schema means the description does not need to detail return values further.
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 the description does not need to elaborate on parameter semantics. The baseline for 0 params is 4, and no further information is required.
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's function: 'Lista todas as features (APIs) disponíveis no mcp-brasil' using a specific verb and resource. It also distinguishes itself from siblings by explaining that it reveals which government APIs are connected and which tools each offers, setting it apart from 'listar_datasets_disponiveis' and 'search_tools'.
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?
Explicit context is provided in 'Use esta tool para saber quais APIs governamentais estão conectadas e quais tools cada uma oferece.' This tells the agent when to use the tool, though it does not explicitly mention alternatives or situations to avoid, preventing a score of 5.
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 explains the tool's behavior in detail: it analyzes the question, identifies tools, order, and dependencies, which implies it only creates a plan and does not execute it. This is transparent and non-misleading.
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 front-loaded, with a one-sentence purpose, a brief but informative explanation, and an Args section. Every sentence adds value, and the example is helpful without verbosity.
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 single parameter, presence of an output schema, and no annotations, the description covers the purpose, usage context, parameter meaning, and provides an example. It is sufficient for an agent to select and invoke this tool correctly.
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 input schema only declares 'query' as a string with no description. The description compensates by explaining it as a natural language question and providing a concrete example, which fully disambiguates the parameter.
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 states a specific action ('cria um plano de execução') for complex queries, and, further details explain it analyzes the question and determines tool order and dependencies. This clearly distinguishes it from sibling tools by emphasizing ordering and dependency analysis beyond mere tool recommendation.
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?
It explicitly states it is useful for queries that need multiple combined calls, which tells an agent when to use it. However, it does not mention when not to use it or explicitly compare it to alternatives like recomendar_tools, so it lacks exclusions.
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-brasil MCP server](https://glama.ai/mcp/servers/Mcp-Brasil/mcp-brasil/badges/card.svg)](https://glama.ai/mcp/servers/Mcp-Brasil/mcp-brasil)

Score Badge

Copy to your README.md:

[![mcp-brasil MCP server](https://glama.ai/mcp/servers/Mcp-Brasil/mcp-brasil/badges/score.svg)](https://glama.ai/mcp/servers/Mcp-Brasil/mcp-brasil)

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/Mcp-Brasil/mcp-brasil'

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