Free lookup of 28.4M active Brazilian companies by CNPJ or name (Receita Federal open data).
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 5 tools
Each tool targets a distinct need: name/CNPJ search, full CNPJ dossier, stock-market data, competitor discovery, and judicial publications. The only mild overlap is that buscar_empresa also accepts a CNPJ, but its summary-result behavior is clearly differentiated from consultar_cnpj's full record.
All names use snake_case and Portuguese, which is readable, but the set mixes imperative verb phrases (buscar_empresa, consultar_cnpj, listar_concorrentes) with noun phrases (dados_bolsa, publicacoes_judiciais). The inconsistency is understandable but not a uniform pattern.
Five tools is well scoped for a focused CNPJ lookup server, with each tool covering a distinct data need. There is no obvious bloat or missing high-level operation that would justify adding many more tools.
The surface covers search, full company detail, stock data, competitors, and judicial publications, which supports most company-dossier workflows. Minor gaps remain around ownership/partners (sócios), tax-regime status, and other registry details that a complete CNPJ dossier might include.
Busca empresas brasileiras ativas pelo nome (razão social ou fantasia) ou CNPJ. Devolve até 20 resultados.
| Name | Required | Description | Default |
|---|---|---|---|
| uf | No | Sigla da UF (opcional) | |
| cidade | No | Município (opcional, exige uf para ser rápido) | |
| consulta | Yes | Começo do nome (fantasia ou razão social) ou CNPJ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two useful traits: only active companies are returned and results are capped at 20. It says nothing about ordering/relevance, pagination or truncation handling, or whether the match is prefix-only.
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 short sentences: what it searches, then the result cap. Zero filler and the key constraint (20 results) is front-loaded.
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 read-only search with no output schema and fully documented parameters, the definition covers scope, search keys, active-only filtering and result cap. Only the ordering/pagination behavior is missing, which is a modest gap.
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 description coverage is 100%, so the baseline is 3. The description restates the name/CNPJ matching already documented in the consulta parameter and adds nothing about the uf/cidade interaction that the schema flags ("cidade" requires "uf").
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?
States a specific verb ("Busca") and resource ("empresas brasileiras ativas") along with the two lookup keys (razão social/fantasia name or CNPJ). The sibling consultar_cnpj is not named, so the boundary between a multi-result search and a single-company lookup has to be inferred from "até 20 resultados".
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?
The "até 20 resultados" cap implies this is the broad search entry point and that consultar_cnpj is for deeper single-company detail, but the description never says when to prefer one over the other and lists no exclusions. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ficha completa de uma empresa pelo CNPJ (14 dígitos): razão social, atividade, endereço, porte, telefone, site e Instagram.
| Name | Required | Description | Default |
|---|---|---|---|
| cnpj | Yes | CNPJ com ou sem pontuação | |
| verificar | No | Conferir a situação cadastral ao vivo na Receita (padrão: true). Também acha CNPJs baixados/inaptos fora da base. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden: it implies a read-only lookup and lists the data returned, which is useful. However, it omits the live-Receita lookup behavior and its cost/latency implications (that only surfaces via the schema's 'verificar' param) and says nothing about error cases for invalid or unknown CNPJs.
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?
A single front-loaded sentence with the resource first and the return payload listed after; no filler or redundancy.
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 two-parameter read tool with full schema coverage and no output schema, listing the returned fields largely substitutes for a return-value section. The main remaining gap is that the overlap with the sibling tool buscar_empresa is never addressed.
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 description coverage is 100%, so both parameters are already documented, and the description only reinforces the CNPJ identifier. Baseline 3 applies since the schema, not the description, explains 'verificar' and its default.
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?
States a specific verb+resource (fetch full company record by CNPJ) and enumerates the returned fields (razão social, atividade, endereço, porte, telefone, site, Instagram), so the agent knows exactly what comes back. It does not distinguish the tool from the sibling buscar_empresa, leaving the reader unsure which lookup to pick.
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 statement of when to use this versus buscar_empresa, which appears to be the alternative lookup tool. The only usage constraint ('14 dígitos') is a format rule, not a selection guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Se a empresa é companhia aberta na B3: tickers, cotação, valor de mercado, P/L e P/VP (Genesis Bolsa, CVM + B3).
| Name | Required | Description | Default |
|---|---|---|---|
| cnpj | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It mentions data sources (Genesis Bolsa, CVM + B3) but says nothing about permissions, rate limits, freshness, failure modes for non-public companies, or what the tool returns beyond a loose field list.
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 compact sentence and the key condition is front-loaded. It is concise, but the terseness leaves out essential invocation guidance, making it under-specified rather than optimally structured.
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?
With no annotations, no output schema, and an undocumented parameter, the description is too thin for an agent to call the tool confidently. It names some return fields but omits parameter semantics, error behavior, and relationship to sibling tools, leaving significant gaps.
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?
The single required parameter, cnpj, is not described at all; schema description coverage is 0%. The description does not explain expected CNPJ format, validation, or whether formatting characters are accepted, so it fails to compensate for the schema gap.
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 indicates the tool returns B3 stock data (tickers, quote, market value, P/L, P/VP) for open companies, which gives a recognizable resource. However, it lacks a clear action verb and does not explicitly distinguish this lookup from sibling tools like consultar_cnpj or buscar_empresa. Purpose is inferable but not sharply defined.
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?
The only usage condition is 'if the company is a publicly traded company on B3', with no guidance on when to choose this tool over alternatives such as consultar_cnpj, buscar_empresa, or listar_concorrentes. There are no exclusions or downstream selection cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Concorrentes de uma empresa: outras empresas ativas com a mesma atividade principal (CNAE) na mesma cidade (ou no estado), mesmo porte primeiro, com contagens.
| Name | Required | Description | Default |
|---|---|---|---|
| cnpj | Yes | ||
| limite | No | até 50 (padrão 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden and does well: it discloses that only active companies are included, that matching is by primary CNAE and city or state, that same-size companies are prioritized, and that counts are returned. It does not cover permissions, rate limits, or exact return structure, but the core selection and ordering behavior is clearly stated.
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, front-loaded sentence with no filler. Every clause adds useful selection or ordering information.
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 moderate-complexity lookup tool with no output schema and no annotations, the description covers the selection logic well but leaves gaps: it does not explain the 'cnpj' input, the effect of 'limite', or the shape of the returned competitor list beyond mentioning counts.
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 description coverage is only 50%, and the description does not compensate by explaining either parameter. The 'limite' parameter has schema guidance ('até 50, padrão 20'), but 'cnpj' is undocumented in both the schema and the description, leaving its expected format unstated.
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 states a specific resource and verb: it lists competitors of a company, defined as other active companies with the same primary CNAE in the same city or state. It is clear what the tool does, but it does not explicitly contrast itself with sibling tools such as buscar_empresa or consultar_cnpj.
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?
Usage is implied by the phrase 'Concorrentes de uma empresa', which suggests competitor analysis. However, there is no explicit when-to-use guidance, no when-not-to-use guidance, and no mention of alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publicações recentes no Diário de Justiça Eletrônico Nacional (CNJ) com a razão social da empresa como parte (casamento por nome exato; pode haver homônimos).
| Name | Required | Description | Default |
|---|---|---|---|
| cnpj | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It usefully names the data source (DJEN/CNJ) and flags a real behavioral risk (exact-name matching, possible homonyms), but says nothing about how far back 'recent' reaches, result volume, pagination, or what a publication record contains.
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?
One sentence, front-loaded with the data source and narrowed by the qualifier about party status and homonyms. No filler, though the missing parameter/return details mean brevity here costs completeness.
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?
No output schema, no annotations, and 0% schema description coverage, so the description is the only source of context — and it omits return fields, time window, and result limits while leaving the CNPJ-vs-name relationship unresolved.
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 description coverage is 0% and the single required parameter is 'cnpj', yet the description talks exclusively about matching the company's 'razão social' by exact name. It never explains how the CNPJ input relates to that name-matching behavior, so the description arguably contradicts rather than clarifies the parameter.
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?
States a concrete resource and scope: recent publications in the CNJ's national electronic justice gazette in which the company is a party. That is enough to distinguish it from the sibling lookups (buscar_empresa, consultar_cnpj, dados_bolsa, listar_concorrentes), though it never names them or explains how it complements them.
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?
There is no when-to-use/when-not-to-use guidance relative to the siblings, and no statement of prerequisites. The only usage-adjacent signal is the parenthetical warning that homonyms may occur, which hints at verification needs but does not route the agent between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
dados_bolsalistar_concorrentespublicacoes_judiciaisconsultar_cnpj1 field changedInput schema / properties / verificarAdded value: +{
+ "description": "Conferir a situação cadastral ao vivo na Receita (padrão: true). Também acha CNPJs baixados/inaptos fora da base.",
+ "type": "boolean"
+}buscar_empresaconsultar_cnpjFree Brazilian CNPJ lookup (legal name, status, partners) + lawsuit discovery. Public data, no login
Brazilian company registry (Receita): CNPJ lookup, CNAE search, idea evaluation, monitoring.
Brazilian company and person data by CNPJ/CPF: registry, partners, tax status, sanctions, lawsuits.
Brazilian business data for AI agents. Public company dossiers by CNPJ.
Add one secure layer between your agents and this server.