Skip to main content
Glama

Get API X402 CNPJ by CNPJ

get_api_x402_cnpj_by_cnpj

CNPJ lookup paid per call, without an account: the Federal Revenue record, the sanctions, the tax standing and the address on the map. The same record as GET /api/consulta/cnpj/:cnpj, for agents: no account, no allowance and no pack. A request without payment gets the 402; a paid one gets the record in the same response, with the payment in uso. A lookup that fails or does not find the company is not charged.

Input Schema

NameRequiredDescriptionDefault
cnpjYesCNPJ with or without punctuation (14 characters).
temasNoComma-separated topics (up to 240 characters): dados, contagens, socios, sancoes, fiscal, divida, obras, trabalho, ibama, contratos, pep, vendas, campanhas, prefeituras, sicaf, aeronaves, fundos, rntrc, bndes, registros; todos. Omit for the full record. Basic company data always stays; partners require socios. contagens adds a contagens object with only the record counts: socios, pep, sancoes, fiscal, socioambiental, governo and registros. Unrequested fields are omitted; null means an unchecked source. SICAF, aircraft and RNTRC select registry agencies; registros includes all agencies. Prices, limits and personal data masking do not change.
cnia_atualNotrue requires a CNIA source check during this request. Source failure returns 503 without charging or using a previous record. Default false. Include sancoes when selecting topics.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / cnia_atual
      Added value: +{
      +  "default": false,
      +  "description": "true requires a CNIA source check during this request. Source failure returns 503 without charging or using a previous record. Default false. Include sancoes when selecting topics.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / temas
      Added value: +{
      +  "description": "Comma-separated topics (up to 240 characters): dados, contagens, socios, sancoes, fiscal, divida, obras, trabalho, ibama, contratos, pep, vendas, campanhas, prefeituras, sicaf, aeronaves, fundos, rntrc, bndes, registros; todos. Omit for the full record. Basic company data always stays; partners require socios. contagens adds a contagens object with only the record counts: socios, pep, sancoes, fiscal, socioambiental, governo and registros. Unrequested fields are omitted; null means an unchecked source. SICAF, aircraft and RNTRC select registry agencies; registros includes all agencies. Prices, limits and personal data masking do not change.",
      +  "type": "string"
      +}
  2. Added

TDQS

A4.1/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: payment is per call, unpaid requests receive 402, successful responses include payment details in `uso`, and failed or not-found lookups are not charged. This is exactly the kind of billing and failure behavior an agent needs before invoking a paid tool.

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 and efficient, covering purpose, payment model, and charge behavior in three sentences. There is minor repetition around no account/no allowance/no pack, but it does not obscure the key 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?

For a three-parameter tool with full schema coverage and no output schema, the description is largely complete: it explains the payment flow, the 402 case, and what happens on failure. It could say more about how payment is supplied or the exact response shape, but the essential invocation context is present.

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%, so the schema already documents all three parameters in detail. The description does not add parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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 a specific operation — a CNPJ lookup — and identifies the returned record contents (Federal Revenue, sanctions, tax standing, address). It also distinguishes this variant by payment model (paid per call, no account), though it does not explicitly name the closest sibling such as consulta_cnpj.

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 context for use: agents without an account, allowance, or pack. It also explains the 402 response when payment is absent, but it does not explicitly compare against named alternatives or state when not to use this tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.