Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-server-brasil consulta CNPJ 11.222.333/0001-81"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Brazilian data APIs as MCP tools. Look up CNPJ, CEP, and live exchange rates (USD/BRL, EUR/BRL) from inside any MCP-compatible client -- Claude Desktop, Cursor, Windsurf, and more.
No API keys required. All sources are free and public (ReceitaWS, ViaCEP, AwesomeAPI).
Tool | Source | What it returns |
| ReceitaWS | Company name, trade name, status, capital, address, partners |
| ViaCEP | Street, neighborhood, city, state, IBGE code, area code |
| AwesomeAPI | Bid/ask, high/low, daily variation for USD and EUR |
In-memory cache on every tool -- avoids duplicate requests and respects ReceitaWS rate limits
Input normalization -- CNPJ/CEP work with or without punctuation
Built-in validation -- rejects malformed CNPJ/CEP before hitting the network
Rate-limit guard -- auto-throttles requests to ReceitaWS (2 s minimum interval)
Zero config, zero API keys
Related MCP server: cnpjaberto
Requirements: Node 18+
git clone https://github.com/davi713albano-coder/mcp-server-brasil.git
cd mcp-server-brasil
npm install
npm run buildThe server runs over stdio and is meant to be launched by an MCP client -- not manually.
Edit claude_desktop_config.json:
OS | Path |
macOS |
|
Windows |
|
{
"mcpServers": {
"brasil": {
"command": "node",
"args": ["/absolute/path/to/mcp-server-brasil/dist/index.js"]
}
}
}Or via npx (once published to npm):
{
"mcpServers": {
"brasil": {
"command": "npx",
"args": ["mcp-server-brasil"]
}
}
}Restart Claude Desktop after editing.
Add to .cursor/mcp.json in your project or global config:
{
"mcpServers": {
"brasil": {
"command": "node",
"args": ["/absolute/path/to/mcp-server-brasil/dist/index.js"]
}
}
}Any client that supports the MCP stdio transport can launch the server the same way. Point the command at node and the first arg at dist/index.js.
consulta_cnpjLooks up a Brazilian company by its CNPJ registration number.
Parameters:
Name | Type | Required | Description |
| string | Yes | 14-digit CNPJ, with or without punctuation |
Example request:
{
"cnpj": "00.000.000/0001-91"
}Example response:
{
"cnpj": "00.000.000/0001-91",
"razao_social": "EMPRESA EXEMPLO LTDA",
"nome_fantasia": "EXEMPLO",
"situacao": "ATIVA",
"data_abertura": "01/01/2000",
"natureza_juridica": "Ltda",
"capital_social": "1000000.00",
"atividade_principal": "Comercio de Exemplo",
"endereco": {
"logradouro": "Rua Exemplo",
"numero": "123",
"complemento": "Sala 4",
"bairro": "Centro",
"cidade": "Sao Paulo",
"estado": "SP",
"cep": "01000-000"
},
"telefone": "(11) 0000-0000",
"email": "contato@exemplo.com",
"sociedades": [
{ "nome": "Joao Silva", "qualificacao": "Socio-Administrador" }
],
"ultima_atualizacao": "01/01/2024"
}consulta_cepLooks up a Brazilian postal code (CEP) and returns the associated address.
Parameters:
Name | Type | Required | Description |
| string | Yes | 8-digit CEP, with or without hyphen |
Example request:
{
"cep": "01001-000"
}Example response:
{
"cep": "01001-000",
"logradouro": "Praca da Se",
"complemento": "lado impar",
"bairro": "Se",
"cidade": "Sao Paulo",
"estado": "Sao Paulo",
"uf": "SP",
"ibge": "3550308",
"ddd": "11"
}cotacao_dolarReturns the latest USD/BRL and EUR/BRL exchange rates. No parameters required.
Example response:
{
"dolar": {
"moeda": "USD/BRL",
"compra": 5.05,
"venda": 5.06,
"alta": 5.11,
"baixa": 5.04,
"variacao": -0.47,
"atualizado_em": "01/01/2024, 15:30:00"
},
"euro": {
"moeda": "EUR/BRL",
"compra": 5.45,
"venda": 5.46,
"alta": 5.51,
"baixa": 5.45,
"variacao": 0.12,
"atualizado_em": "01/01/2024, 15:30:00"
}
}No environment variables or API keys are needed. The server uses free public APIs:
Tool | Upstream API | Rate limit |
| 3 requests / min (free tier). The server auto-throttles to 2 s between calls and caches results in memory. | |
| Generous; results are cached in memory | |
| 20 requests / min (free); results are not cached (live rates) |
# install dependencies
npm install
# build TypeScript
npm run build
# watch mode
npm run devCPF lookup (with proper authentication)
Vehicle plate lookup (SINESP API)
Docker image for easy deployment
Unit tests
TTL-based cache eviction
npm publish for npx support
PRs are welcome. To add a new API tool:
Create src/your-tool.ts with valida and consultar exports
Register it in src/index.ts inside the TOOLS array and the switch handler
Open a PR with a clear description of the tool and its upstream API
Consulta endereço pelo CEP usando ViaCEP. Retorna logradouro, bairro, cidade, estado.
| Name | Required | Description | Default |
|---|---|---|---|
| cep | Yes | CEP com ou sem hífen. Ex: 01001000 ou 01001-000 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions using ViaCEP but does not inform about potential limitations (e.g., rate limits, reliability) or error handling (e.g., invalid CEP).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action and output. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with a single required parameter and no output schema, the description adequately lists return fields. However, it lacks details on error states and service reliability, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description in the schema already explains the hyphen format. The tool description repeats this without adding new semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool consults an address by CEP using ViaCEP and lists the return fields. It is distinct from siblings which handle CNPJ and currency queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 is provided. However, sibling tool names imply different domains, so usage context is loosely inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta dados de empresa pelo CNPJ (ReceitaWS). Retorna razão social, atividade principal, capital social, situação, endereço, sócios etc.
| Name | Required | Description | Default |
|---|---|---|---|
| cnpj | Yes | CNPJ da empresa. Aceita com ou sem pontuação. Ex: 00000000000191 ou 00.000.000/0001-91 |
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 mentions returned data but does not disclose behavioral traits such as authorization requirements, rate limits, error handling, or any side effects. The description is insufficient for understanding the tool's behavior beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. It avoids unnecessary words and clearly communicates the tool's purpose and return values. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description is complete for an agent to understand what it does and what it returns. It lists key return fields, which compensates for the lack of output schema. However, some behavioral context is missing (see transparency score).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter description in the schema already explains the CNPJ format (with or without punctuation). The tool description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: consulting company data by CNPJ using ReceitaWS. It lists specific returned fields (business name, main activity, etc.), and the sibling tools (consulta_cep, cotacao_dolar) are distinct, so no confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings, but the naming and description indicate it's for CNPJ queries, which is distinct from CEP or dollar rate tools. Implicit usage context is present but no exclusions or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cotação atual do dólar e euro em relação ao BRL (AwesomeAPI).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It indicates a read operation ('current quotation') but lacks details on data freshness, rate limits, or source reliability beyond mentioning 'AwesomeAPI'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. However, it is so brief that it under-specifies some aspects; a slightly longer description with structured details would improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain what the return data contains (e.g., values, timestamps). For a simple tool, this may be acceptable, but completeness is hindered by the lack of return format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description adds no param details beyond the schema. Baseline for 0 parameters is 4, and no further clarification is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides current exchange rates for USD and EUR to BRL, matching the tool name and distinguishing it from siblings (consulta_cep, consulta_cnpj) which handle different data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool versus alternatives, though siblings are clearly for different domains. No explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a unique and clearly distinct purpose: one for address lookup by CEP, one for company data by CNPJ, and one for currency exchange rates. There is no overlap in functionality.
Two tools use the 'consulta_' prefix (query), while the third uses 'cotacao_' (rate). While all are descriptive and in snake_case, the prefix inconsistency is a minor deviation from a uniform pattern.
With 3 tools, the server is slightly on the smaller side but still within a reasonable range for a focused query service. The number of tools matches the server's apparent scope of providing common Brazilian data lookups.
The server covers three common Brazilian data queries (address, company, exchange rate) without obvious missing operations for its intended read-only purpose. Minor gaps like historical rates or additional data types exist but do not hinder basic usage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
CNPJ Brazil MCP — Brazilian company-registry (Receita Federal) lookup via
Brazilian fiscal MCP server - issue NF-e, NFC-e, NFS-e, CT-e, MDF-e and DC-e via SEFAZ.
Official-source lookups on people and companies: registration status (CPF/CNPJ), Simples/MEI, SINTEG
# MCP DadosBR Servidor MCP focado em dados públicos do Brasil. Oferece duas ferramentas simples e…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/davi713albano-coder/mcp-server-brasil'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
