Brazilian company checks by CNPJ: registry, sanctions, federal contracts and CVM, with sources.
Scored across 5 tools
Each tool maps to a distinct data source (cadastro, sanções, contratos, CVM), and relatorio_completo is explicitly framed as an aggregate with clear guidance on when to use it versus the individual tools. No two tools appear to do the same thing, and the descriptions anticipate the natural confusion between the bundle and its components.
All names use consistent snake_case Portuguese noun phrases (cadastro_empresa, sancoes_empresa, contratos_publicos, registro_cvm), which is predictable. The only slight deviation is relatorio_completo, a meta/aggregate tool rather than a single data source, but it still fits the naming style.
Five tools is well-scoped for a CNPJ due-diligence server: four atomic data sources plus one aggregate. Each earns its place, with no redundancy or filler.
The surface covers the core due-diligence pillars (registration, federal sanctions, federal contracts, CVM status) plus a one-call aggregate. Gaps exist — federal-only scope, no partner/ownership data — but these are explicitly documented as deliberate limits rather than silent omissions.
Cadastro de empresa brasileira por CNPJ (com ou sem máscara).
Quando usar: para situação cadastral, CNAE, porte, capital social, natureza jurídica e localização. Para cadastro + sanções + contratos + CVM de uma vez, use relatorio_completo.
Dados públicos da Receita Federal obtidos via terceiros (BrasilAPI, com
OpenCNPJ de reserva), sem garantia de completude ou atualidade. Não é
aconselhamento jurídico ou financeiro. Não retorna dados de pessoas físicas:
sem sócios, e-mail ou telefone; para empresário individual e MEI, omite
razão social, nome fantasia e endereço. Cada fonte consultada vem em fontes
com seu status; erro de fonte não vira lista vazia. CNPJ inválido é rejeitado
antes de qualquer consulta.
| Name | Required | Description | Default |
|---|---|---|---|
| cnpj | Yes | CNPJ da empresa, 14 dígitos, com ou sem pontuação (ex.: 33.000.167/0001-01 ou 33000167000101). Os dígitos verificadores são validados antes de qualquer consulta; CNPJ inválido é rejeitado sem chamar as fontes. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnly/openWorld/idempotent/non-destructive) by disclosing data provenance (BrasilAPI with OpenCNPJ fallback), absence of completeness/freshness guarantees, no personal-data fields (sócios, e-mail, telefone), the MEI/empresário-individual omission of razão social/nome fantasia/endereço, per-source status in `fontes`, and that source errors do not yield empty lists. These are non-obvious behaviors an agent must know to interpret results correctly.
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?
Front-loads purpose then usage, and every subsequent sentence carries a real constraint (provenance, omissions, `fontes`, invalid-CNPJ rejection). It is slightly long and includes boilerplate disclaimers ('não é aconselhamento jurídico') that do not aid tool selection, keeping it from a 5.
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?
An output schema exists, so return-shape explanation is unnecessary, and the description usefully references the `fontes` field and error semantics. For a single-parameter lookup, it covers provenance, limitations and edge cases thoroughly.
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 single parameter's description already documents mask tolerance and pre-query check-digit validation. The description's 'com ou sem máscara' and 'CNPJ inválido é rejeitado antes de qualquer consulta' largely restate the schema, so the baseline of 3 applies.
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 ('Cadastro de empresa brasileira por CNPJ') and enumerates exactly what data it returns (situação cadastral, CNAE, porte, capital social, natureza jurídica, localização). It also names the sibling relatorio_completo as the alternative for a combined lookup, so the agent can distinguish it without opening schemas.
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?
Contains an explicit 'Quando usar' clause listing the qualifying data categories, plus an explicit exclusion/redirect: for cadastro combined with sanções/contratos/CVM, use relatorio_completo. This is exactly the when-to-use/when-not/alternative structure that earns top marks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Contratos de empresa brasileira (por CNPJ, com ou sem máscara) com o Poder Executivo Federal.
Quando usar: para histórico de fornecimento ao governo federal (órgão, objeto, datas, valores). Para a visão completa, use relatorio_completo.
Fonte: Portal da Transparência (CGU), dados públicos, sem garantia de
completude ou atualidade. Cobre SOMENTE contratos do Poder Executivo Federal
registrados no Portal: ausência de contratos NÃO significa que a empresa não
tenha contratos com estados, municípios ou outros poderes. Não é
aconselhamento jurídico ou financeiro. Não retorna dados de pessoas físicas
(sem contato de responsável). limite (1 a 100, padrão 20) define quantos
contratos devolver: os mais recentes por data de assinatura, entre todos os
encontrados (até 150 por CNPJ). total_encontrado é o total lido;
possivelmente_mais: true indica que o teto de leitura foi atingido. Filial também consulta a
matriz (outro_estabelecimento). Erro da fonte vem em fontes e dados é
null, nunca lista vazia.
| Name | Required | Description | Default |
|---|---|---|---|
| cnpj | Yes | CNPJ da empresa, 14 dígitos, com ou sem pontuação (ex.: 33.000.167/0001-01 ou 33000167000101). Os dígitos verificadores são validados antes de qualquer consulta; CNPJ inválido é rejeitado sem chamar as fontes. | |
| limite | No | Quantos contratos devolver, de 1 a 100: os mais recentes por data de assinatura. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial context beyond them: the data source (Portal da Transparência/CGU), no completeness or currency guarantee, scope limits, no legal advice, no personal data, filial consulting matriz, and the error contract (source error in `fontes`, `dados` null, never an empty 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?
Front-loads purpose, then a labeled usage clause, then source/limitations, then parameter behavior. Every sentence carries information (limitations, scoping, error contract), though the density is high and a couple of clauses could be trimmed without loss.
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 two-parameter lookup with an output schema, the description is complete: source, coverage boundaries, parameter semantics, ceiling behavior, and failure-mode shape are all covered, leaving no ambiguity about what the tool returns or fails to cover.
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%, so the baseline is 3, but the description adds real semantics beyond the schema: `limite` selects the most recent by data de assinatura among all found (up to 150 per CNPJ), and it explains the related return signals `total_encontrado` and `possivelmente_mais: true` as the read-ceiling indicator.
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 and resource: returns a Brazilian company's contracts with the federal executive, keyed by CNPJ. It also explicitly names the sibling that gives the broader view (relatorio_completo), so an agent can route between the two without opening schemas.
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?
Includes an explicit 'Quando usar' clause tied to a concrete need (supply history to the federal government with órgão, objeto, datas, valores) and names the alternative for the full picture. It further states when NOT to rely on the result: absence of contracts only means absence in the federal executive, not for states/municipalities or other branches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Registro de companhia aberta na CVM por CNPJ (com ou sem máscara).
Quando usar: para saber se a empresa é companhia aberta registrada na CVM, a situação do registro, a categoria e o auditor. Para a visão completa, use relatorio_completo.
Cadastro de companhias abertas da CVM (dados abertos, ODbL, arquivo diário):
dados públicos, sem garantia de completude ou atualidade. Não é aconselhamento
jurídico ou financeiro. Não retorna dados de pessoas físicas (sem diretor de
relações com investidores, e-mail, telefone ou endereço). registrada: false
com fonte ok significa que o CNPJ não consta no arquivo da CVM. Uma empresa
pode ter mais de um registro (ex.: um cancelado e um ativo); registros traz
todos, com o não cancelado primeiro. Falha de download vem em fontes.
| Name | Required | Description | Default |
|---|---|---|---|
| cnpj | Yes | CNPJ da empresa, 14 dígitos, com ou sem pontuação (ex.: 33.000.167/0001-01 ou 33000167000101). Os dígitos verificadores são validados antes de qualquer consulta; CNPJ inválido é rejeitado sem chamar as fontes. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial unique behavior: data provenance (CVM open data, ODbL, daily file), no completeness/freshness guarantee, disclaimer that it is not legal or financial advice, explicit absence of PII, the interpretation of `registrada: false` with `fonte: ok`, the possibility of multiple registros with the non-cancelled one first, and download failures surfacing in `fontes`.
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?
Front-loaded with purpose, then the when-to-use block, then provenance and edge-case semantics — a logical ordering where each paragraph earns its place. Slightly long and the CNPJ format note duplicates the schema, but there is no filler.
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?
An output schema exists, so return values need not be enumerated, yet the description still supplies the interpretive keys an agent needs (registrada:false vs fonte:ok, multiple registros ordering, fontes on failure). For a mutation-free single-parameter lookup this is complete.
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 validation rules and accepted formats (14 digits, with or without punctuation, check digits validated) are already fully documented in the schema. The description's 'com ou sem máscara' simply restates that, adding no new parameter meaning — baseline 3 applies.
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 and resource — 'Registro de companhia aberta na CVM por CNPJ' — and scopes it to the CNPJ lookup. An agent can distinguish this from cadastro_empresa, sancoes_empresa or contratos_publicos without opening any schema.
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?
An explicit 'Quando usar' block states the question this tool answers (whether the company is a registered open company, its status, category and auditor) and names the sibling to use instead for the full view: relatorio_completo. Both the trigger and the alternative are given, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Relatório de checagem de empresa brasileira por CNPJ (com ou sem máscara), em uma chamada.
Quando usar: checagem inicial, KYC ou due diligence, quando se quer o quadro todo numa chamada. Se só uma parte interessa, a ferramenta individual responde mais rápido.
Consulta em paralelo cadastro (Receita Federal), sanções (CEIS, CNEP, CEPIM e leniência),
contratos com o Poder Executivo Federal e registro de companhia aberta na CVM. Devolve
dados: {cadastro, sancoes, contratos, cvm, completo, secoes_com_falha}, onde cada seção é
o dados da ferramenta correspondente. Retorno parcial: seção cuja fonte falhou ou estourou
o tempo vem null, listada em secoes_com_falha, e o status de cada fonte está em fontes;
completo: true só se nenhuma seção falhou. Dados públicos, sem garantia de completude; sanções
e contratos cobrem só a esfera federal, e ausência não prova inexistência. Não é aconselhamento
jurídico ou financeiro, não traz dados de pessoas físicas e não tem score nem juízo de risco.
limite_contratos (1 a 100, padrão 10) = quantos contratos recentes devolver.
| Name | Required | Description | Default |
|---|---|---|---|
| cnpj | Yes | CNPJ da empresa, 14 dígitos, com ou sem pontuação (ex.: 33.000.167/0001-01 ou 33000167000101). Os dígitos verificadores são validados antes de qualquer consulta; CNPJ inválido é rejeitado sem chamar as fontes. | |
| limite_contratos | No | Quantos contratos recentes incluir na seção de contratos, de 1 a 100. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower, yet the description adds substantial behavior: parallel fan-out to four sources, partial-return semantics (failed sections arrive as null and are listed in secoes_com_falha, per-source status in fontes, completo only when nothing failed), and coverage caveats (federal sphere only, absence ≠ non-existence, no completeness guarantee).
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?
Purpose and when-to-use are front-loaded, and the return-shape and limitation sentences each carry distinct information. It is long, but this is a complex aggregator and nearly every clause earns its place; only the limite_contratos recap is mildly redundant.
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 multi-source aggregator with an output schema and full annotations, the description still supplies the failure semantics, coverage limits, and scope disclaimers an agent needs to interpret results responsibly. Nothing material is missing.
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 in the schema; the description's restatement of limite_contratos (1–100, default 10) and the with/without-mask CNPJ note duplicates rather than extends the schema. Baseline 3 is appropriate where the schema does the heavy lifting.
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 (full Brazilian-company check report by CNPJ) and enumerates exactly what it aggregates: cadastro/Receita Federal, sanções/CEIS-CNEP-CEPIM, contratos federais, and CVM registry. It also distinguishes itself from the per-source siblings by framing itself as the aggregate call and the individual tools as the faster alternative.
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 'Quando usar' clause names concrete scenarios (checagem inicial, KYC, due diligence) and provides an explicit exclusion plus alternative: when only one part matters, the individual tool is faster. The section names (cadastro, sanções, contratos, cvm) map directly onto the sibling tools, so the routing is inferable without opening any schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sanções de empresa brasileira por CNPJ (com ou sem máscara) nos cadastros federais.
Quando usar: para saber se a empresa está impedida, inidônea, punida pela Lei Anticorrupção ou tem acordo de leniência na esfera federal. Para a visão completa, use relatorio_completo.
Consulta CEIS, CNEP, CEPIM e acordos de leniência do Portal da Transparência
(CGU): dados públicos, sem garantia de completude ou atualidade. "Nada consta"
(lista vazia com fonte ok) significa apenas ausência nesses 4 cadastros
federais, não em bases estaduais, municipais ou privadas. Não é aconselhamento
jurídico ou financeiro. Não retorna dados de pessoas físicas (registros de CPF
são descartados). Cada cadastro vem em fontes com seu status; cadastro que
falhou tem null em dados, nunca lista vazia. truncado: true indica que a
consulta atingiu o teto de páginas.
| Name | Required | Description | Default |
|---|---|---|---|
| cnpj | Yes | CNPJ da empresa, 14 dígitos, com ou sem pontuação (ex.: 33.000.167/0001-01 ou 33000167000101). Os dígitos verificadores são validados antes de qualquer consulta; CNPJ inválido é rejeitado sem chamar as fontes. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false), but the description adds substantial behavioral context: what 'Nada consta' actually means, that failures surface as null in `dados` rather than an empty list, that `truncado: true` signals a page cap, and that CPF records are discarded. This is exactly the value-add beyond structured fields.
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?
Content is front-loaded (purpose, then when-to-use, then caveats) and every clause carries information, though the caveat block is dense and slightly longer than needed. Structure is logical and skimmable.
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 an output schema present and rich annotations, the description covers the remaining gaps an agent needs: scope limits (four federal registries only, no state/municipal), the null-vs-empty distinction, truncation signaling, and the no-PF-fields constraint. Nothing material is missing.
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% for the single `cnpj` parameter and the schema already documents the masked/unmasked format and check-digit validation. The description's 'com ou sem máscara' merely echoes the schema, so baseline 3 applies with no meaningful addition.
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 first sentence names a specific resource (empresa brasileira sanctions by CNPJ) and enumerates the exact federal registries covered (CEIS, CNEP, CEPIM, leniência). It also explicitly distinguishes itself from the sibling relatorio_completo, so an agent can route correctly without opening either schema.
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?
A dedicated 'Quando usar' clause states the triggering condition (impedida, inidônea, punida pela Lei Anticorrupção, acordo de leniência) and points to the alternative (relatorio_completo) for the full view. Both when and which-alternative are explicit.
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.
cadastro_empresacontratos_publicosregistro_cvmrelatorio_completosancoes_empresaBrazilian company and person data by CNPJ/CPF: registry, partners, tax status, sanctions, lawsuits.
Consolidated lookup of a company at the Federal Audit Court (TCU) from the CNPJ, gathering sanctions
Vet a Brazilian company by CNPJ: official registry data plus its Reclame Aqui reputation.
Free Brazilian CNPJ lookup (legal name, status, partners) + lawsuit discovery. Public data, no login
Add one secure layer between your agents and this server.