MCP Brazil Public Data

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools are distinct (CNPJ, CEP, DDD, ISBN, bank, broker, domain are clearly separate). However, list_rates/get_rate and list_currencies/get_exchange_rate are legitimate duos, but list_banks/get_bank alongside list_rates/get_rate create a repetitive pattern where the list/get pairing could cause an agent to pick the wrong 'get' for a given symbol/code. list_states and list_municipalities are related but distinct enough.
Naming Consistency4/5
The set follows a mostly consistent pattern: list_X for enumeration (list_states, list_banks, list_holidays, list_rates, list_currencies, list_municipalities), lookup_X for single-record lookups by identifier (lookup_cnpj, lookup_cep, lookup_ddd, lookup_isbn, lookup_broker), and get_X for fetching specific values (get_bank, get_rate, get_exchange_rate). The mixing of 'lookup' and 'get' for similar operations is the only inconsistency, though both are clear.
Tool Count4/5
15 tools is slightly on the higher side but reasonable for a broad 'public data' server covering multiple domains (geography, companies, finance, telecom, books, domains). Each tool targets a distinct data source, so none feel redundant. Could arguably be trimmed, but the scope justifies the count.
Completeness3/5
The server covers a broad but shallow set of disjoint domains. Within each domain there are clear gaps: holidays has no state/municipal holidays (noted in description), banks has list+get but no search-by-name, rates/currencies are read-only with no historical range beyond specific date for exchange. The domain is inherently a heterogeneous reference service, so completeness is hard to define, but several common lookups (e.g., CNPJ search by name, CEP range) are absent.
Average 3.8/5 across 15 of 15 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on July 20, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does state what the tool returns (name and current value), which is helpful. However, it doesn't disclose whether this is a real-time quote, delayed data, cached values, or what happens for invalid symbols. Moderate transparency but not comprehensive.
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 efficient and well-structured: two sentences with the purpose in the first and return value in the second. No wasted words or redundant information. Slightly more could be done but it's appropriately sized for a simple single-parameter tool.
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 a single parameter with 100% schema coverage and an output schema exists. For a simple lookup tool, the description provides the essential purpose and return format (name and current value). The output schema handles return value details. Complete enough for the tool's simplicity, though could mention data freshness/caching behavior.
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% with the symbol parameter clearly documented with examples (SELIC, CDI, IPCA). The description mentions 'by its symbol' which reinforces the parameter usage. Baseline 3 is appropriate since the schema already does the heavy lifting, and the description adds minimal additional semantic value beyond confirming the parameter exists.
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 what the tool does: get the current value of an economic rate/index by its symbol. The verb 'Get' with resource 'current value of an economic rate/index' is specific. However, it doesn't explicitly distinguish itself from sibling tools like get_exchange_rate or list_rates, though its symbol-based lookup for rates like SELIC/CDI/IPCA does imply this distinction.
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 implies usage context (lookup by symbol) but provides no explicit guidance on when to use this tool versus alternatives like get_exchange_rate or list_rates. There's no when-not-to-use guidance, no mention of situations where this tool is preferred or inappropriate.
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 the cardinality (27 states) and the four fields returned (id, abbreviation, name, region), which is useful context. However, it doesn't mention ordering, pagination, or any completeness caveats, though as a static list of 27 fixed entities these may be less critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero filler. It front-loads the purpose and adds specific detail about the fields. Every sentence 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?
The tool has no parameters, no annotations, and is a straightforward list of a fixed, well-known set (27 Brazilian states). The description adequately covers what the output contains. An output schema exists, so return-value documentation is not the description's job. Minor gap: it doesn't mention any sorting order, but for a fixed census list this is acceptable.
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 0 parameters, so there's nothing to document. Per guidelines, 0 params warrants a baseline of 4. The description compensates appropriately by explaining what each returned item includes.
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 it lists 27 Brazilian federative units with their IBGE codes, using a specific verb (list) and resource (states). It distinguishes itself from siblings like list_banks and list_rates by specifying Brazilian states and IBGE codes, which is distinct from other list tools.
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 explains what the tool returns but doesn't provide explicit when-to-use guidance or mention alternatives. Since it's a no-parameter list tool among several sibling list tools, there's no clarification on how this differs from list_municipalities or when to prefer one over the other.
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?
This is a read-only lookup tool with no annotations provided, so the description carries the burden. It states what it returns (state and municipalities) but doesn't disclose behavior for invalid/unknown DDD codes, error handling, or formatting of the returned list. For a read-only tool, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that pack purpose and return-value summary without waste. Front-loaded with the key action and resource. Slightly redundant with the schema's parameter description, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only lookup with a full input schema and an output schema present, the description is reasonably complete. It explains what's returned (UF + municipalities). It doesn't need to over-explain given the output schema handles return details.
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 description coverage is 100%, so the 'ddd' parameter is fully documented as a 2-digit area code with an example. The description adds minimal extra meaning beyond confirming the parameter drives state/municipality lookup. Baseline 3 is appropriate given full schema coverage.
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 uses a specific verb ('Look up') with a clear resource (Brazilian area code / DDD) and defines the output (state UF + municipalities). It distinguishes from siblings like lookup_cep, lookup_cnpj, and list_municipalities, though it doesn't explicitly name alternatives.
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 implicitly conveys usage context (looking up DDD area codes for Brazilian regions) but provides no explicit when-to-use guidance or notable exclusions/alternatives. Context is inferable from the siblings, but no alternative tools are named.
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 behavioral disclosure burden. It does describe the return contents (ISPB, name, full name, bank code), which is useful. However, it doesn't disclose error behavior for invalid codes, rate limits, or whether the code is case-sensitive/formatted, leaving gaps for a read tool with zero annotation coverage.
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 crisp sentences that front-load the purpose and enumerate return fields with zero waste. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a 1-parameter tool, 100% schema coverage, and an output schema present (which presumably documents the return structure), the description adequately covers purpose and return values. It's complete for a simple lookup tool, though no explicit failure-mode notes.
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%, and the schema itself documents the code parameter with format and example ('001 for Banco do Brasil'). The description adds little beyond restating 'COMPE code'. Baseline 3 is appropriate since the schema already carries the param documentation burden.
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 'Get a bank's data by its COMPE code' with a specific verb+resource+identifier, and lists the returned fields (ISPB, name, full name, bank code). It clearly describes what the tool does, though it doesn't explicitly distinguish from sibling tool list_banks, which is also bank-related.
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 is for fetching a single bank by code, contrasting implicitly with list_banks. However, it does not explicitly provide when/when-not guidance or name alternatives for related operations.
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 discloses that quotes are only available on business days and that returns are PTAX buy/sell rates, which is useful behavioral context. However, it doesn't explain what happens on non-business days (empty response? error?) or whether there are rate limits or auth requirements, which a read-only economic-data tool with zero annotation coverage could reasonably disclose.
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?
Two compact paragraphs with zero fluff. Front-loaded with purpose, then behavioral detail. Efficient and to the point. Minor deduction only because it omits any mention of what happens for non-business days, which could have been a short clarifying note.
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?
An output schema exists, so return structure doesn't need explanation. Parameters are fully covered at 100% schema coverage. Business-day constraint is disclosed. For a straightforward read-only lookup tool with two simple params, this is reasonably complete. It could note handling of invalid dates or unavailable quotes, but the core usage is covered.
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% and both parameters are well-documented in the schema (date format YYYY-MM-DD with business-day note, currency symbol example). The description adds marginal value by implying the date must be a business day, but this is already present in the schema. Per rubric, baseline 3 is appropriate when schema carries the load.
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?
Clear verb+resource ('Get the buy/sell exchange rate of a currency on a specific date'). It specifies it returns PTAX rates (buy/sell), which adds specificity. It doesn't explicitly differentiate from siblings like get_rate or list_rates, but the purpose is clear enough that the agent can likely distinguish them.
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 and schema both emphasize that quotes are only available on business days, and the date parameter description reinforces 'Use a business day; weekends and holidays have no quote.' This is clear context on when to use the tool. It doesn't explicitly name alternatives or exclusions, but the business-day constraint is actionable 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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It communicates the read-only nature implicitly ('List' and 'Returns') and states the output shape (name and IBGE code). However, it doesn't describe pagination, ordering, or behavior for an invalid state code.
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?
Two sentences, front-loaded with the purpose statement and followed by a one-line output clarification. Zero waste, though the second sentence somewhat repeats the first ('Returns the name and IBGE code' echoed in 'with their IBGE codes'). Efficient but not perfectly lean.
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?
With one parameter, 100% schema coverage, and an output schema present, the description is reasonably complete for a simple listing tool. It doesn't need to explain return values since an output schema exists. The only gaps would be edge behavior (invalid UF, sort order), which are minor for this tool type.
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% — the uf parameter is documented with examples (SP, RJ, MG). The description adds the semantic that the parameter maps to a state whose municipalities are returned, but the schema already provides the 2-letter abbreviation meaning. Baseline 3 is appropriate given full 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 clearly states what the tool does: 'List the municipalities of a state with their IBGE codes.' It uses specific verb+resource (list municipalities) and is distinct from sibling tools like list_states (states, not municipalities) and other lookups. It also adds the scope qualifier 'of a given state' and specifies output includes IBGE codes.
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 takes a state (uf parameter) and returns municipalities, making the usage context clear. However, it doesn't explicitly state when to use this vs alternatives, nor any exclusions or prerequisites. The sibling set is varied enough that no explicit alternative is named.
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 behavioral burden. It does disclose it aggregates from multiple providers and specifies which fields are returned 'when available,' implying possible missing data. However, it doesn't clarify data freshness, potential ISBN format normalization, or what happens for unknown ISBNs.
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?
Two sentences, front-loaded with the primary purpose in the first sentence and return fields in the second. Zero wasted words. Slightly low on structural formatting (no breaks) but appropriately tight for the content.
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?
With an output schema present and a single well-documented parameter, the description doesn't need to explain return types. The aggregation provider list and field enumeration provide useful context. A small gap is not framing the 'when available' caveat more explicitly, but overall this is reasonably complete for a simple lookup tool.
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% with the isbn parameter well-documented (ISBN-10 or ISBN-13, with or without hyphens). The description adds context about what the lookup returns but doesn't add parameter-level semantics beyond what the schema already covers, which is the baseline-3 scenario.
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+resource ('look up a book's metadata by ISBN') and lists the exact fields returned (title, authors, publisher, year, synopsis, dimensions). It clearly distinguishes from siblings like lookup_cnpj and lookup_cep which target different entity types.
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 implicitly conveys use for looking up book metadata and names the aggregated provider sources (CBL, Mercado Editorial, Google Books), but provides no explicit when/when-not guidance or alternatives. For a lookup tool with clearly distinct siblings by entity type, this is adequate but not exemplary.
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 behavioral disclosure burden. It correctly implies this is a read-only operation by describing it as a 'look up' returning registered data. However, it doesn't disclose potential edge cases like unknown CNPJs (does it throw or return empty?), data recency, or CVM data update cadence.
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 two tightly-written paragraphs: one sentence for the core action and one for the returned data fields. Every sentence earns its place with no fluff or repetition of schema information.
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?
With an output schema present, the description needn't enumerate the full return structure, but it helpfully names the key returned fields (trade name, legal name, status, address, contacts). For a simple one-parameter lookup tool with complete schema coverage, the combination of description, schema, and output schema provides adequate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the sole parameter 'cnpj' already has a clear description including the punctuation-flexibility note (14 digits, with or without punctuation). The tool description reinforces the CNPJ is the lookup key but adds no new semantic detail beyond the schema, so baseline 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 the verb ('look up') and resource ('CVM-authorized brokerage firm') and specifies the lookup key (CNPJ). The return payload is enumerated (trade name, legal name, status, address, contacts), distinguishing it from sibling tools like lookup_cnpj which is a general CNPJ lookup, not broker-specific.
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 establishes clear context that this is for CVM-authorized (regulatory) brokerage firms in Brazil, which implies use when needing regulatory registration data. However, it does not explicitly state when to prefer this over the sibling lookup_cnpj or what limitations exist (e.g., only CVM-authorized firms), nor does it give exclusions.
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 clearly describes this as a read-only status check and discloses what it returns (status, suggestions, creation/expiration/last-processed dates for registered domains). This is a non-mutating lookup, and the description effectively communicates the behavioral scope despite lacking explicit safety language.
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?
Two short paragraphs, front-loaded with the core purpose. Concise and to the point. Minor deduction because the second sentence explaining return values could arguably be folded more tightly, but overall it is efficient with no wasted 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?
Has an output schema and 100% parameter coverage, which reduces the burden on the description. It adequately explains the tool's function and return-value category (status, suggestions, dates). For a one-parameter read-only lookup tool, this is reasonably complete, though it could mention the output schema structure or multilingual/asynchronous behavior if any.
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%, and the parameter 'domain' has a clear example (nubank.com.br). The description reiterates what 'domain' means implicitly. Baseline 3 applies since the schema handles the single parameter well; the description adds no additional formatting rules beyond what the schema example provides.
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?
Clear verb+resource: 'Check the status of a .br domain at Registro.br.' It distinguishes from siblings since it's the only domain-checking tool among lookup/list tools for CNPJ, CEP, DDD, ISBN, etc. The scope (.br, Registro.br) is explicit.
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 .br domain availability/status but does not explicitly state when to use it vs alternatives. Given siblings are unrelated lookups (CNPJ, CEP, DDD), differentiation is intuitive, but no explicit when/not-to-use 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 full burden. It discloses that this is a read-only listing operation (implied by 'List all banks'), which is reasonable. It mentions the approximate count (~250 institutions), which adds useful context about scale. However, it doesn't disclose details about pagination, response limits, or whether optional filtering exists. Given the HTTP GET-like nature implied by 'list', the behavioral transparency is acceptable 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?
Three sentences, zero wasted words. It specifies scope, output contents, and usage guidance efficiently. Every sentence earns its place—the first states what it does, the second details output fields, and the third provides a concrete use case.
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 a simple parameterless list operation with an output schema present, which means return values are structurally documented. The description covers its purpose and use case well. It could slightly benefit from noting whether results are ordered or if there are pagination concerns, but for a straightforward 0-parameter listing tool, the coverage is thorough and appropriate.
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 0 parameters with 100% schema coverage, meaning the schema accurately reflects that no inputs are required. The description adds meaningful semantic information about what the output contains (COMPE code, ISPB, name, full name) and notes the approximate scale. With zero parameters, the description's role in parameter semantics is minimal, but it does add value by explaining the output fields which relates to what a caller should expect.
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 it lists all banks registered in Brazil (~250 institutions) and specifies what each item includes (COMPE code, ISPB, name, full name). It uses a specific verb+resource structure. It doesn't explicitly differentiate from siblings like list_rates or list_currencies, but those are clearly different domains, so sibling confusion is minimal.
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 explains a concrete use case: 'Useful to discover a bank's code before calling get_bank.' This provides clear context on when to use this tool. It doesn't explicitly state when NOT to use it, but given the sibling list (list_states, list_rates, etc.), the distinction is fairly self-evident. The guidance is helpful but could be slightly more explicit about alternatives.
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 context. It discloses what each item reveals (symbol, name, type) and that returns a list of currencies. However, it does not describe the return format details beyond per-item fields, error behavior, or ordering. Adequate basic transparency 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?
Two tight sentences. The first states the purpose and examples; the second describes output fields and a pointer to downstream usage. Zero 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 (0 params, no nested objects) and has an output schema, so the description need not enumerate return types. The pointer to get_exchange_rate fills the usage context well. Slightly incomplete only in not clarifying the relationship to the sibling list_rates (which might be a related 'rates' listing), but this is minor.
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?
Zero parameters exist, so there's nothing to document. Per the rubric, 0 params earns a baseline of 4. The description correctly confirms no inputs are needed and no param semantics gaps exist.
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?
Clear verb+resource: 'List the foreign currencies available for quotes.' It specifies that it lists currencies with symbol, name, and type. Distinguishes from siblings like list_banks, list_states, list_holidays, though not from the closely-related list_rates. The '(USD, EUR and others)' gives helpful concrete examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use the returned symbol with get_exchange_rate.' This connects the tool to a downstream consumer (get_exchange_rate, a sibling tool), showing when/how the output is used. Doesn't explicitly say when NOT to use it, but with 0 params and a clear list purpose, exclusion guidance is less critical.
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 transparently discloses that it returns date (YYYY-MM-DD), name, and type for each holiday, and clarifies exclusion of state/municipal holidays — a boundary that helps the agent understand exactly what results to expect. This is useful behavioral context beyond what the schema conveys.
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 at two sentences, front-loaded with the core purpose in the first sentence. The second sentence adds useful behavioral detail (return fields) that doesn't repeat the schema. No wasted words, though it could arguably be trimmed.
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 a single, well-documented parameter and an output schema explaining results. The description covers purpose, return content, and scope boundaries. With simple complexity, this level of description is adequate and complete for the tool's needs.
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% — the year parameter is already well-documented in the schema with an example ('4-digit year (e.g. 2026)'). Per rubric, baseline is 3 when schema does the heavy lifting, and the description adds no extra parameter-specific semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists 'Brazilian national holidays for a given year' with a specific verb (List), resource (Brazilian national holidays), and scope (for a given year). It explicitly excludes state and municipal holidays, distinguishing it from sibling tool list_municipalities and list_states.
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 clearly identifies the tool's scope as national-only holidays and explicitly notes it does not include state or municipal holidays, implying when to use it (federal context) and hinting that list_municipalities/list_states would be alternatives for more granular queries. However, it does not provide explicit 'use when' guidance or name sibling alternatives directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It's a read-only list operation, and the description implies this by saying 'list' and 'available.' It discloses the data source (BACEN via BrasilAPI) and field names, but doesn't describe pagination, rate-limits, or how fresh the 'current values' are. Adequate but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences with zero waste. Describes the tool, gives example indicators, and notes the source. Front-loaded purpose, all sentences earn their 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 zero-parameter list tool with an output schema, this is reasonably complete. It could add pagination or count details, but with no params and an output schema present, the description covers the essential purpose, contents, and source adequately.
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?
There are 0 parameters and schema coverage is 100% (empty object is fully described by schema). With no params, the description adds clarity about what items are returned (nome, valor). No parameter documentation burden to carry, so a solid score 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?
Clear verb+resource: 'List all available economic rates and indices with their current values.' Specifically names the indicators (SELIC, CDI, IPCA) and describes the item structure (nome, valor). Distinguishes from siblings like get_rate (which is singular/filtered) and list_currencies (FX).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance, nor alternatives named. However, it identifies source (BACEN via BrasilAPI) which gives some context. The sibling get_rate suggests there's a targeted alternative, but this isn't mentioned. Usage is only implied.
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 the data source and what information is returned, which is helpful. However, it does not address behavior such as error handling for invalid CNPJs, network dependency on BrasilAPI, rate limiting, or what happens for inactive/suspended registrations. Decent context but several behavioral aspects remain undisclosed.
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 tightly structured: a one-line purpose statement followed by a compact enumeration of returned fields and the data source. Every sentence earns its place with no redundancy or fluff. Front-loaded with the primary action and resource.
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 output schema exists, so return value details are covered elsewhere. With just one parameter at 100% schema coverage, the description is largely complete for what an agent needs: the source, the fields, and the purpose. The only minor gap is behavioral aspects like error handling, but for a single-param public API lookup the description is quite sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there is only 1 parameter. The schema already documents that cnpj is 14 digits with or without punctuation, and the description complements this by explaining that the tool retrieves Federal Revenue registration data. The description adds the source context and output richness that informs how the single parameter is interpreted. With a single well-documented param, the baseline is inherently high.
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 ('Look up') with a clear resource ('registration data of a Brazilian company by its CNPJ'). It explicitly enumerates the returned fields (legal name, trade name, status, CNAE, address, partners, share capital), which clearly distinguishes it from siblings like lookup_cep, lookup_ddd, and lookup_cep which target different Brazilian identifiers.
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 identifies the source (Brazilian Federal Revenue via BrasilAPI) and the output shape, which gives useful context. However, it does not explicitly state when to use this vs alternatives, nor any exclusions or prerequisites (e.g., no mention of rate limits, or scenarios where the tool is inappropriate). Usage context is implied rather than explicitly guided.
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 transparency burden. It discloses that the tool aggregates multiple providers (Correios, ViaCEP, and others), which is a useful behavioral detail. It also notes that geographic coordinates are returned 'when available,' honestly disclosing optionality. It doesn't mention error behavior for invalid CEPs, but the core behavioral profile is well 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 tight and well-structured: one lead sentence stating the purpose, a concise list of returned fields, and a brief note about the underlying API. Every sentence earns its place with no filler or redundancy.
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 (single required param), has an output schema to describe return values, and the description covers purpose, the data source, and the conditional nature of coordinates. For a straightforward lookup tool, this is complete. It could theoretically mention error/not-found behavior but that's a minor gap given the overall 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?
Schema coverage is 100% — the single 'cep' parameter is fully described with format ('8-digit', with or without hyphen, e.g., 01310-100). The description doesn't add much beyond the schema because there's only one parameter and it's fully specified there. Baseline 3 is appropriate when schema handles parameter documentation.
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+resource ('Look up the full address for a Brazilian postal code (CEP)') and clearly states what it returns (street, neighborhood, city, state, geographic coordinates). It distinguishes itself from sibling tools like lookup_cnpj, lookup_ddd, and lookup_broker by being specifically about postal code lookup.
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 implicitly conveys usage context by naming the data source (BrasilAPI's CEP v2 endpoint) and listing returned fields. It doesn't explicitly say when NOT to use it or name an alternative tool, but there is no sibling tool that appears to compete with lookup_cep since all other lookup_* tools target different data types (companies, DDD, ISBN, brokers).
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-brazil-public-data MCP server](https://glama.ai/mcp/servers/devantage/mcp-brazil-public-data/badges/card.svg)](https://glama.ai/mcp/servers/devantage/mcp-brazil-public-data)

Score Badge

Copy to your README.md:

[![mcp-brazil-public-data MCP server](https://glama.ai/mcp/servers/devantage/mcp-brazil-public-data/badges/score.svg)](https://glama.ai/mcp/servers/devantage/mcp-brazil-public-data)

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/devantage/mcp-brazil-public-data'

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