mcp-brasil

Server Quality Checklist

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

Latest release: v0.2.1
Disambiguation5/5
Each tool targets a distinct resource and action (e.g., population vs PIB vs municipalities vs generic SIDRA), and within each source (IBGE, BCB, INMET, Camara) the functions are clearly separated—list vs details vs votes. There is no meaningful overlap that would cause an agent to misselect.
Naming Consistency5/5
All tools follow a consistent 'source_noun' pattern with snake_case (ibge_populacao, bcb_serie, inmet_estacoes, camara_deputados). The only slight variation is the use of singular vs plural nouns, but this is a natural linguistic choice and does not break the overall consistency.
Tool Count5/5
With 14 tools, the server is well-scoped for its purpose of aggregating Brazilian public data across four distinct domains. No tool feels redundant, and the count is within the optimal 3–15 range, striking a good balance between breadth and focus.
Completeness4/5
Each domain is reasonably covered: IBGE has core indicators plus generic SIDRA, BCB has time series, exchange rates, currency list, and market focus, INMET has stations and data (with token gate), and Camara offers deputies, details, propositions, and votes. Minor gaps exist (e.g., no Camara session coverage, no direct inflation series), but the generic SIDRA tool compensates for many potential lacks, and the core workflows are achievable.
Average 3.8/5 across 14 of 14 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on August 25, 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does reveal the tool is a read operation returning 'projeção média' (average projections) for future periods, which covers the essential nature. However, it adds no depth on data currency/update cadence or period granularity, which would be useful context for an expectations tool.
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?
The content is compact and front-loaded with the purpose before the Args section, but it suffers from redundancy ('Boletim Focus (Boletim Focus)') and an awkward code-style leak of the Args block into the description. Every sentence earns weight, but the duplicate phrasing and mixed formatting detract from polish.
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 has one parameter whose values are documented in the description, and an output schema is present, so return-value documentation is not needed. For a simple single-indicator read tool, the definition is mostly complete, with only minor gaps around what 'próximos períodos' concretely covers.
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 0%, so the description must compensate. It does enumerate the valid values for 'indicador' ('selic', 'ipca', 'pib' ou 'cambio'), which goes beyond the bare schema. However, it adds no meaning about what each indicator represents or how 'cambio' differs from actual exchange-rate data, so the compensation is partial.
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?
States a clear verb+resource: 'Mostra a projeção média dos analistas de mercado' from the Boletim Focus, the Central Bank's market expectations survey. It identifies the specific data source, which helps separate it from siblings like bcb_serie and bcb_cambio. It could be more explicit about how it differs from those alternatives, but the core purpose is unambiguous.
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 versus alternatives. There is no mention of contexts, exclusions, or references to siblings such as bcb_serie or bcb_cambio, even though the 'cambio' indicator could plausibly overlap with bcb_cambio. The agent is left to infer usage from the purpose statement alone.
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 carries the full burden of behavioral disclosure. It does not explicitly state that this is a read-only operation, nor does it describe the response format, pagination, or any potential side effects. While 'busca' implies a read, it is not stated, and given the absence of annotations, this is a 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 efficient and well-structured. The main purpose is stated in a single sentence, followed by a clearly separated 'Args' section. Every sentence adds value, and examples are embedded without verbosity. It is front-loaded with the core function.
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 presence of an output schema reduces the need to explain return values. However, the description lacks usage guidance (when to use vs alternatives) and behavioral notes (read-only, error handling). It also does not address the fact that all parameters are optional and whether any combination is required. These omissions make it incomplete for a tool with multiple siblings and free-form search.
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?
Schema description coverage is 0%, but the description compensates thoroughly. Each parameter (ano, palavras_chave, sigla_tipo) is explained with a definition and concrete examples ('ex.: 2025', 'ex.: "saude mental"', 'ex.: "PL", "PEC", "MPV"'). This adds meaning beyond the schema's bare titles and is exactly what a low-coverage schema needs.
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 verb 'Busca' (searches) and the resource 'proposições legislativas na Câmara', listing examples like projetos de lei and emendas. It is specific and unambiguous, though it does not explicitly distinguish itself from sibling tools such as camara_votacoes_proposicao. The resource is clear enough that an agent can infer its purpose.
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?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description only explains what it does, not when to invoke it. For instance, it does not mention that camara_votacoes_proposicao would be more appropriate for voting data. This is a significant gap for a search tool with multiple sibling 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Lista' clearly implies a read-only operation, and the source (Banco Central) and type (moedas com cotação PTAX) are stated. However, it does not disclose potential limitations such as data volume, rate limits, or the exact structure of the returned list, which would be expected for a listing 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 a single, efficient sentence that front-loads the core action and resource. There is no redundant information or filler, making it appropriately concise and well-structured for quick parsing by an agent.
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 has an output schema (though not detailed), the description provides sufficient context for a basic listing operation. It names the data source (Banco Central) and the specific type (moedas com cotação PTAX), which is adequate for understanding the tool's scope. It could be more complete by explicitly stating that this is for listing available currencies for use in other BCB tools, but this is a minor gap.
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, and the schema confirms this with 100% coverage. The baseline for 0 parameters is 4, and the description appropriately adds no parameter-specific details since none exist. It effectively communicates that no input is required, beyond the implicit context of the tool's purpose.
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 verb 'Lista' and the resource 'moedas com cotação PTAX disponíveis no Banco Central', making the purpose specific and distinct from vague alternatives. However, it does not explicitly differentiate from sibling tools like bcb_cambio or bcb_serie, which could be confused for similar financial data operations.
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 offers no guidance on when to use this tool versus its siblings. It simply states what it does, leaving the agent to infer usage context. There is no mention of exclusions or alternative conditions, so agents may not know when this listing is preferred over bcb_cambio or bcb_serie.
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 provided, the description must carry the full burden of behavioral disclosure. It only states that it lists deputies with filters; it does not mention pagination, ordering, data limits, or how filters are combined (e.g., AND). It also does not describe the response structure beyond what an output schema would provide, but since the output schema exists, that is partially covered.
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 efficiently structured with a brief purpose sentence followed by a compact parameter list. Every sentence is informative and there is no redundant content. The format is easy to scan and understand.
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 tool with four optional parameters and an output schema, the description covers the purpose and parameter semantics well. It mentions the default for legislatura. However, it does not specify how filters interact (e.g., whether they are combinable) or whether results are complete without pagination. Given the output schema exists, this is nearly complete but misses minor behavioral details.
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 description explicitly explains each parameter with examples and delimiters (e.g., 'uf: Sigla da unidade federativa, ex.: "SP", "MG"'). This adds significant value beyond the input schema, which only provides types and defaults. It also clarifies that 'legislatura' defaults to the current one, which is not evident from the schema.
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 resource (federal deputies of the Câmara) and the verb 'Lista' (list). It also indicates optional filters. However, it does not differentiate from sibling tools like camara_detalhes_deputado, which likely fetches details for a single deputy, so an agent could be unsure whether to use this for listing or details.
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 is provided on when to use this tool versus alternatives. The description mentions optional filters but does not explain under what circumstances one would prefer this tool over siblings such as camara_proposicoes or camara_detalhes_deputado. There are no explicit exclusions or prerequisites.
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 full burden of behavioral disclosure. It states the tool returns quotes for the last N business days and mentions the default of 7. However, it does not disclose error behavior, rate limits, or anything about the return format beyond what an output schema would cover. The description is honest but not deeply detailed about potential side effects or edge cases, though none are expected for a read-only query.
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 concise and front-loaded with the purpose, followed by parameter explanations. Each sentence earns its place, and the structure (statement then Args) is clean. Slightly under-structured with a plain paragraph, but effective and without fluff.
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 an output schema (so return format is documented elsewhere), two optional parameters with defaults, and a pointer to a related tool, the description covers what an agent needs to invoke it correctly. It lacks explicit error handling or examples, but these are less critical given the simplicity and the schema.
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 description coverage is 0%, so the description must compensate. It explains both parameters: 'moeda' gives symbol examples (USD, EUR, GBP) and refers to bcb_moedas for the full list, and 'dias' clarifies it is the number of business days of quotes with a default of 7. This adds meaningful semantic detail beyond the bare schema.
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 tool returns Central Bank PTAX exchange rate quotes for a currency over the last N business days. It identifies a specific resource (exchange rates) and action (retrieving quotes). It does not explicitly differentiate from sibling tools like bcb_serie or bcb_focus, but the purpose is unambiguous and distinct enough given the 'PTAX' specificity.
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 provides contextual guidance by pointing to bcb_moedas for listing available currencies, which is helpful for parameter selection. However, it does not explain when to prefer this tool over other BCB or IBGE tools, nor does it state any exclusions. Usage context is implied but 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?
With no annotations, the description carries the burden of behavioral disclosure. It mentions defaults for data_inicial and data_final, which is useful, but doesn't state that the operation is read-only, any rate limits, or side effects. It partially fills the gap but leaves significant behavioral traits unstated.
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 concise, with a clear intro and a structured parameter list. It avoids verbosity while including essential examples and defaults. The format is front-loaded with purpose, followed by parameter details, though it could be slightly more compact by moving examples inline.
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's simplicity and the presence of an output schema, the description covers necessary usage specifics: required code, optional dates, and defaults. It lacks details on pagination or limits, but these are not explicitly needed for basic invocation and the output schema handles return format.
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 description thoroughly explains each parameter: codigo with multiple concrete examples, date formats, and defaults. Since the schema has zero descriptions, this compensation is crucial and effectively makes the tool callable without further research.
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 tool queries time series from Banco Central's SGS system, using a specific verb ('Consulta') and resource. It differentiates from siblings by naming the source system, though it doesn't explicitly contrast with other BCB tools like bcb_cambio or bcb_focus, so it's clear but not fully distinguished.
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 alternatives, such as bcb_cambio or bcb_focus. It gives code examples but no context for selection criteria among sibling tools, leaving the agent to infer applicability.
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 full burden of behavioral disclosure. It does disclose one useful behavior — omitting `ano` returns the most recent available period — and the operation is clearly a non-destructive read. However, it does not describe data frequency, units, whether long-run series may include gaps, or any response details; with an output schema present, return structure is covered elsewhere. The disclosure is adequate but thin.
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 tight: a one-line purpose followed by two concise parameter notes. It is front-loaded with the core purpose, and every sentence earns its place. The args block overlaps somewhat with the input schema, but it adds value through the 'BR' hint and default-period behavior, so 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?
Given the tool's simplicity (a single-value GDP lookup for a UF/year) and the presence of an output schema, the description covers purpose, both parameters, and the default behavior adequately. The main gap is the unresolved relationship to the sibling `ibge_sidra`, which an agent might confuse with this tool given the shared source name.
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?
Schema description coverage is 0%, so the description fully compensates. Both parameters are explicated: `uf` is defined as a UF abbreviation with examples ('MG', 'BA') or 'BR' for the national total, and `ano` is defined as the reference year with the omit-for-most-recent behavior. This adds real meaning beyond the bare schema property names.
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 states a specific operation — returning PIB at current prices for a federation unit or Brazil — and names the source (IBGE/SIDRA). It distinguishes itself from siblings by topic (PIB vs. populacao, municipios, BCB, INMET, camara), so an agent can tell it apart by subject. However, it shares its source with the sibling `ibge_sidra`, and the description does not clarify how it differs from that more general tool, which slightly weakens differentiation.
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?
There is no explicit guidance on when to use this tool versus alternatives. The parameter hints (e.g., 'BR' for national total, omit ano for the most recent period) give operational context, but nothing tells the agent when to prefer this over `ibge_sidra` or how to choose among the IBGE siblings. Usage is only implied by the GDP topic, with no exclusions or explicit routing.
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 full burden. It does disclose one important behavior: when 'ano' is omitted, the tool returns the most recent available period. This adds practical context beyond the schema's default of null. However, it does not disclose other behavioral aspects such as data source specifics, pagination, or any error-handling behavior. For a read-only tool, the description is adequate but not rich.
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, consisting of a one-sentence purpose followed by two bullet-point parameter explanations. It front-loads the core purpose and each parameter is described in a single line. There is zero redundancy; every sentence earns its place, making it easy to scan and 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?
For a simple two-parameter lookup tool with an output schema, the description covers the purpose, parameter usage, and a key default behavior. It does not mention alternatives or edge cases, but given the simplicity and presence of an output schema, nothing critical is missing. A brief note on when to use this versus ibge_sidra would improve completeness, but it is not essential for correct invocation.
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?
Schema description coverage is 0%, so the description must explain the parameters. It does so thoroughly: 'uf' is defined with examples ('SP', 'RJ') and 'BR' for national total, and 'ano' is explained with the default behavior when omitted. This goes well beyond the schema which only gives types and defaults, fully equipping the agent to supply valid inputs.
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 tool returns resident population data for a Brazilian state or the entire country, sourced from IBGE/SIDRA. It names the data type and geographic scope, which distinguishes it from sibling tools that focus on GDP (ibge_pib), municipalities (ibge_municipios), or general SIDRA queries (ibge_sidra). However, it does not explicitly name any sibling or delineate when to prefer this tool over others, stopping short of full differentiation.
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 population queries by stating what it returns, but does not provide explicit guidance on when to use this tool versus alternatives like ibge_pib or ibge_sidra. It lacks exclusionary conditions or mention of other tools. The context is clear enough (you use it when you need population of a UF or Brazil), but the absence of alternative routing is a gap.
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 full burden. It explains parameters and provides a link to the aggregate list, but does not disclose behavioral traits like read-only nature, potential response size, pagination, or rate limits. It implies a network call but lacks explicit safety or side-effect notes. Adequate but not rich for a zero-annotation tool.
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 docstring is well-structured with a clear one-line purpose followed by parameter explanations. It is concise and every sentence adds value, with examples and a link. Slightly long but acceptable for a generic API with multiple parameters.
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 presence of an output schema (per context signal), the description correctly focuses on input semantics. It covers all parameters, provides reference material, and is sufficient for an agent to construct a valid call. Minor gaps include no mention of error conditions or pagination, but these are not critical for initial invocation.
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?
Schema coverage is 0%, so the description fully compensates by providing concrete examples for every parameter: 'agregado' with ID examples and a URL, 'variavel' with an example, 'localidades' with format 'N1[1]' and place examples, and 'periodos' with ranges. This is far beyond what the schema offers, making parameter usage unambiguous.
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 verb ('Consulta genérica') and resource ('API SIDRA do IBGE') with explicit scope 'para qualquer indicador'. It clearly differentiates itself from the specific sibling tools (ibge_populacao, ibge_pib) by being generic, so an agent can immediately understand this is a universal wrapper.
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 generic applicability but does not explicitly name alternatives or provide when-not-to-use guidance. It doesn't say 'use specific tools for population or PIB' or warn against using this for known indicators. The absence of explicit routing to sibling tools leaves some inference burden on the agent, though the generic phrasing suggests it is a fallback.
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. 'Lista' implies a read-only operation, but the description does not disclose any additional behaviors such as pagination, rate limits, or authorization requirements. For a simple listing tool this is acceptable, but it lacks depth.
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 concise, leading with the purpose in the first sentence and then detailing the argument. The 'Args:' section is slightly redundant with the schema but adds value by explaining the parameter's origin. No wasted words.
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 tool with one parameter and an output schema present, the description provides the core information: what it does and how to get the required ID. The output schema covers return values, so that omission is not an issue. Some minor details like result ordering or pagination are absent but not critical.
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 input schema has no description for the parameter, and schema coverage is 0%. The description compensates by explaining that id_proposicao is an ID numérico da proposição and indicates where to obtain it (camara_proposicoes). This fully clarifies the single parameter's meaning and source.
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 'Lista as votações realizadas para uma proposição específica da Câmara' with a specific verb (Lista) and resource (votações for a proposição). It differentiates from siblings like camara_proposicoes by focusing on votes for a specific proposition.
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 mentions that id_proposicao is 'obtido via camara_proposicoes', which implicitly tells the agent to first fetch propositions from that sibling tool to get the ID. It doesn't explicitly state when to use this tool versus alternatives, but the source reference provides clear context for usage.
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 provided, the description carries the burden of behavioral disclosure. It states 'não requer autenticação' (no authentication required), which is useful. However, it does not mention any other behavioral aspects such as pagination, rate limits, or whether the list is complete or filtered. While the core operation is clear, the description is thin on additional behavior. This is adequate for a simple list tool but lacks depth.
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 concise and front-loaded with the main purpose. The Args section is efficient, listing each parameter and its meaning in a compact format. It could be slightly better formatted, but everything included earns its place without redundancy.
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 that an output schema exists, the description need not explain return values. The tool is simple (2 parameters), and both are fully explained. The authentication note adds context. The description covers all necessary aspects for correct invocation, 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description fully compensates. It explains both parameters: tipo with allowed values ("T" for automatic, "M" for conventional) and uf as an optional filter with an example. This adds critical meaning beyond the schema's types and defaults, making parameter usage unambiguous.
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 clear verb and resource: 'Lista estações meteorológicas do INMET' (lists INMET weather stations). It is specific and distinguishes the tool from sibling 'inmet_dados' by focusing on station listing rather than data retrieval. The note about authentication adds an extra clarifying detail.
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 does not explicitly state when to use this tool versus alternatives like inmet_dados. It implies usage through the name and purpose (listing stations) but provides no direct comparison or exclusion. The parameter details (tipo, uf) are explained, but there's no guidance on choosing this over siblings. This is adequate but not 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 carries the full burden. It discloses that name matching is partial ('total ou parcial'), which is valuable. But it does not mention return format, pagination, or error behavior. For a read-only search tool, this is a moderate gap, hence a 3.
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 compact, two sentences plus args. The main purpose is front-loaded, and the additional args are clearly listed with examples. No wasted words.
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 two parameters, and an output schema exists (not detailed in the description, but inferred). The description covers the essential input semantics (partial name, optional UF) and leaves return format to the output schema. It's nearly complete; a minor addition could be specifying that the result is a list of matching municipalities, but that's likely covered by the output schema.
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?
Schema description coverage is 0%, so the description must compensate, and it does. It explains 'nome' allows partial matches and 'uf' is an optional filter with an example. This adds meaning beyond the schema, which only defines string types.
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 verb 'busca' (search), the resource 'municípios brasileiros' (Brazilian municipalities), and the source (IBGE). It distinguishes itself from sibling tools like ibge_populacao or ibge_pib by focusing on municipality lookup rather than statistical data.
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 explains the optional UF filter and gives examples, making the common use case clear. However, it does not explicitly contrast with alternatives or state when not to use it; but the sibling tools are clearly different (population, PIB, etc.), so the context is sufficient.
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?
Annotations are absent, so the description must carry the full burden of behavioral disclosure. It mentions the token prerequisite but does not disclose other behavioral aspects such as response format, error handling, rate limits, or side effects. For a data retrieval tool, this is a significant gap; the token requirement is the only behavioral detail provided.
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: a concise purpose line, followed by prerequisite information, then a clear parameter listing. It is front-loaded with the core purpose and uses minimal words to convey essential details. No redundant or verbose sentences.
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's simplicity, the description covers the key context: token requirement, station code retrieval, and parameter limits. An output schema exists (though its contents are not shown), so return format need not be described. However, it still lacks mention of potential errors or edge cases (e.g., invalid station code, token expiry), which suggests a slight incompleteness for a production 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?
The schema has zero descriptions, so the description fully compensates. It explains both parameters: 'estacao' with an example ('A001') and how to obtain codes (via inmet_estacoes), and 'dias' with default and maximum values. This is more than sufficient for an agent to correctly fill in the arguments.
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 its purpose: returns hourly observed data from an automatic INMET station for the last days. It uses a specific verb ('Dados horários observados'), names the resource (automatic INMET station), and explicitly differentiates itself from inmet_estacoes by saying to use that tool for listing stations. This is sufficient to distinguish it from all sibling tools.
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?
It provides explicit usage guidance: requires the INMET_TOKEN environment variable and states 'Sem token, use inmet_estacoes' as an alternative. It also directs users to list station codes with inmet_estacoes, covering both when-to-use and when-not-to-use, with concrete fallback instructions.
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 of behavioral disclosure. It honestly conveys a read/fetch operation and what fields it returns. It does not disclose error behavior for invalid or nonexistent IDs, which is the main gap, but for a straightforward ID-based lookup the description is transparent about its purpose.
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 short sentences that front-load the purpose, followed by a minimal parameter note. There is zero waste, and the workflow pointer to camara_deputados earns its place.
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 single-required-parameter lookup with an output schema present (which covers return format), the description covers purpose, returned fields, parameter meaning, and parameter source. The only missing piece is error handling for invalid IDs, which is a minor gap for a simple detail-fetch 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?
With 0% schema description coverage, the bare schema only labels the field 'Id Deputado'. The description compensates by explaining that id_deputado is the numeric deputy ID and, importantly, that it is obtained via camara_deputados, adding semantic value 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 a specific verb and resource ('Detalhes de um deputado federal pelo ID') and lists the returned fields (nome civil, partido, UF, gabinete). It also distinguishes itself from the sibling list tool camara_deputados by noting the ID is obtained from that tool, so an agent can tell lookup-details apart from list-deputies.
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 a clear two-step workflow: first call camara_deputados to obtain the ID, then call this tool for details. This gives context on when to use it, though it does not explicitly state alternatives or when not to use it. For a simple lookup this is adequate, but exclusions are not spelled out.
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/lucianoon/mcp-brasil/badges/card.svg)](https://glama.ai/mcp/servers/lucianoon/mcp-brasil)

Score Badge

Copy to your README.md:

[![mcp-brasil MCP server](https://glama.ai/mcp/servers/lucianoon/mcp-brasil/badges/score.svg)](https://glama.ai/mcp/servers/lucianoon/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/lucianoon/mcp-brasil'

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