Confere (Brasil)

Conferir empresa brasileira

conferir_empresa

Read-onlyIdempotent

Check a Brazilian company (CNPJ) before paying it: registration status at Receita Federal, company age and registered name. Does not compare the payee (the paid door does). Returns signals with their sources and lists what was not checked; it does not assert fraud. Website checks are not active in this version. Confere empresa (CNPJ) antes de um pagamento. Free, rate-limited.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "conferir_empresa"
  }
}

Input Schema

Name	Required	Description	Default
`cnpj`	No	CNPJ of the Brazilian company, with or without punctuation (the alphanumeric format is accepted). CNPJ da empresa, com ou sem pontuação.

Output Schema

Name	Required	Description
`resumo`	Yes	Reading of what WAS checked: no alerts in the items checked, caution, alert, or not enough to check. A clean value never covers the items in `nao_conferido`. Leitura do que foi conferido.
`sinais`	Yes
`empresa`	No	Public registry data of the company, present when the CNPJ was found.
`leitura`	Yes	One sentence in Portuguese: the reading, what was checked and what was not. Pass it on. Uma frase com o alcance da conferência.
`limites`	Yes	General limits of this check. Limites gerais desta checagem.
`ambiente`	Yes
`conferido`	Yes	What this lookup checked. O que foi conferido.
`recebedor`	Yes	Comparison of the payee the bank shows with the registry. 'confere' does not prove who owns the account. Comparação do recebedor.
`consultado_em`	Yes	Time of the lookup (ISO 8601, UTC).
`nao_conferido`	Yes	What this lookup did NOT check, and why. Tell the person. O que não foi conferido.
`cnpj_consultado`	No	The CNPJ that was looked up, formatted. CNPJ consultado.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/openWorld/idempotent annotations, it discloses that results carry signals with their sources, that unchecked items are listed, that it does not assert fraud, that website checks are inactive, and that the service is free but rate-limited. That is substantial behavioral context an agent could not get from the annotations alone.

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 front-loaded with the purpose and covers the key caveats in a few dense sentences, with no filler. The duplicated Portuguese sentence is mildly redundant but plausibly serves a bilingual audience rather than wasting space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description need not detail return values, yet it still characterizes them as sourced signals plus a list of unchecked items. Combined with the scope limits and rate-limit note, an agent has everything needed to call this correctly.

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 schema already explains punctuation tolerance and the alphanumeric format, so the description adds no further parameter meaning. The baseline of 3 is appropriate when the schema carries the full burden for a single parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Check a Brazilian company (CNPJ)') and enumerates exactly what is verified: registration status at Receita Federal, company age, and registered name. It also explicitly bounds scope by saying it does not compare the payee, so an agent knows what this tool is and is not.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear timing context ('before paying it') and points to an alternative for payee comparison, though the reference ('the paid door does') is a garbled translation that an agent may not be able to resolve reliably. It also rules out website checks in this version, which usefully narrows expectations, but there are no explicit exclusions for when not to confer at all.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Confere (Brasil) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?