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

With no annotations, the description carries the full behavioral burden and does well: it lists returned fields (CNPJ, situação, município, natureza jurídica, porte, capital) and warns that 'contem' reads ~1 GB on first use in a session, taking about 1 minute over the internet. It does not mention pagination, rate limits, or auth, but the performance warning is unusually valuable.

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 front-loaded with purpose, then return fields, then modes, then the critical 'contem' warning. Every sentence earns its place, and the structure mirrors the agent's decision order without any 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?

Given no annotations, no output schema, and low schema coverage, the description is quite complete: it covers purpose, return values, mode behavior, default, and a key performance caveat. The main gap is the absence of any mention of 'uf' and 'limite', which leaves optional filtering and result-count behavior entirely to the schema.

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 low (25%), so the description must compensate. It explains the 'texto' meaning (razão social or trecho) and fully details the 'modo' enum values, default, and trade-offs, but it completely omits the optional 'uf' and 'limite' parameters, leaving half the schema without added meaning.

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 verb (Procura) and resource (empresas) qualified by 'pela razão social', making the tool's purpose immediately clear. It also distinguishes the 'contem' mode's broader scope (including trade name of the headquarters), which helps separate it from a generic filter search.

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?

It gives strong guidance for mode selection: 'prefixo' is default and fast, 'exato' exists, and 'contem' should be avoided unless the beginning of the name is unknown, with a concrete performance cost. However, it gives no guidance on when to use this tool versus siblings like buscar_empresas_por_filtro or consultar_cnpj, leaving tool-level selection implied.

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

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

With no annotations, the description carries the full burden and does disclose two behavioral traits: the no-key public API source and the cursor-based pagination contract. It omits how multiple filters combine (AND/OR), rate or result limits, and the return shape, so it is adequate but not rich.

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?

Three tight sentences with no filler, and the critical constraint ('Informe ao menos um filtro') is front-loaded before the pagination detail. Structure is efficient, only losing a point for packing source attribution into the purpose sentence.

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 7-parameter, no-annotation, no-output-schema search tool, the description covers the required-filter rule and pagination, which are the two highest-risk behaviors. It leaves the response format and multi-filter combination semantics undocumented, so it is minimally sufficient rather than 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 coverage is 100%, so the schema already documents all seven parameters, and the description merely echoes the filter fields. It notably does not disambiguate the subtle cnae vs cnae_fiscal distinction present in the schema, so no value is added beyond structured data. 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 (Lista) and resource (estabelecimentos) and enumerates the four filter dimensions (UF, CNAE, município, natureza jurídica), plus names the data source. It is clear what the tool returns, though it never names a sibling like buscar_empresa_por_nome or empresas_no_endereco, so the agent must infer differentiation.

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?

'Informe ao menos um filtro' gives an explicit minimum-input constraint, and the pagination sentence prescribes the repeat-with-cursor workflow. However, it never states when to prefer this tool over the many sibling search tools, nor any exclusions, so usage is only implied.

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

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

With no annotations, the description carries the full burden and does so well: it discloses output composition (homônimos agrupados por CPF mascarado, faixa etária, contagem de empresas, UFs/municípios), per-mode latency, a first-call ~130 MB download for 'contem', and the caveat that 'contem' omits municípios. This is exactly the cost/behavior context an agent needs before choosing a mode.

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?

Four dense sentences, front-loaded with the core action, then output shape, then workflow routing, then mode trade-offs. No filler; every clause carries 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?

With no annotations and no output schema, the description compensates by describing both behavior and returned fields, which is enough to invoke the tool correctly. Minor gaps remain (the purpose/behavior of 'limite' and any default value) but nothing critical 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 60%; 'modo' has no schema description but the description fully explains its three values with performance implications, adding real meaning beyond the enum list. 'uf' and 'cpf' are already documented in the schema, and 'limite' remains unexplained in both places, keeping this below a 5.

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 (procura) and resource (pessoas/empresas no quadro societário) scoped to name lookup, and clearly separates itself from the sibling buscar_empresa_por_nome by operating on sócios rather than empresas. An agent can distinguish it from every sibling without opening the 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?

Explicitly routes the workflow with 'Use antes de empresas_do_socio', giving clear sequencing context and naming the follow-up tool. It does not state when NOT to use it versus alternatives like buscar_empresa_por_nome, so it falls short of a full when/when-not treatment.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses the data provenance (Minha Receita primary, OpenCNPJ and CNPJá as fallback) and that the response flags the source used, which is real behavioral value. It does not, however, cover rate limits, caching, or what happens on an unknown/invalid CNPJ, which matters for a tool aggregating free public APIs.

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?

Compact and front-loaded: the returned payload is described first, then the source/fallback behavior. Every clause earns its place and 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?

With no output schema, the description compensates by enumerating returned fields and noting the source indicator. That covers the essentials for a single-parameter lookup tool; only error/failure semantics are 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% and the single parameter already documents that masked or unmasked 14-digit input is accepted. The description adds no format, validation, or normalization detail beyond the schema, so the 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 concrete verb+resource ('Ficha completa de um CNPJ') and enumerates the returned fields (razão social, situação, endereço, CNAEs, Simples/MEI, sócios), so the agent knows exactly what it gets. It is implicitly distinct from siblings like buscar_empresa_por_nome or socios_em_comum, but it never names an alternative, so differentiation is left to the agent.

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 only implied: the tool takes a CNPJ, so an agent infers it should be used when a CNPJ is in hand and name/socio/address lookups should use the other tools. There is no explicit when-to-use statement, no prerequisite (e.g. valid CNPJ required), and no named alternative for the case where the agent lacks a CNPJ.

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

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

No annotations are provided, so the description carries the burden. It implies a read-only listing and explains the homonym-disambiguation behavior, which is useful, but says nothing about result limits, pagination, or what happens when multiple partners match the name.

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 dense sentences, no filler, with the purpose stated first and the input guidance second. Every clause 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?

With no output schema and no annotations, the description does reasonable work by naming the returned attributes and the input disambiguation strategy. It falls short only on volume/limit behavior and failure modes for ambiguous names.

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 already 100%, so the baseline is 3, but the description adds real value: it explains why CPF is preferred (excluir homônimos) and that CNPJ alone returns the companies where a legal entity is a partner, clarifying the semantics of each parameter's combination.

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 ('Lista as empresas em que... figura como sócia') and even names the fields returned (situação, município). It is clearly distinguishable from siblings like buscar_socio or consultar_cnpj because it returns the reverse relationship (companies for a given partner).

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?

Gives conditional input guidance: use the exact name as returned by buscar_socio, preferably plus CPF to disambiguate homonyms, or only CNPJ to list a legal entity's participations. It references the sibling buscar_socio as the source of the name, but does not state when not to use this tool versus the other sibling lookups.

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

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, and it does not disclose the default value or effect of somente_ativas (i.e. whether inactive registrations are returned), pagination behavior, or result-size limits. For a listing tool with zero annotation coverage and no output schema, this is a notable gap.

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 tight sentences, purpose first and use case second, with no filler. It is appropriately sized for a five-parameter lookup tool.

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 five parameters, 60% schema coverage, no annotations and no output schema, the description leaves the agent guessing about default filtering, result limits and matching behavior. It covers purpose and motivation but not the operational details needed to invoke the tool confidently.

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 60%. The description restates numero and logradouro, which the schema already documents, and adds no format or matching semantics (e.g. partial vs exact matching for logradouro). The limite and somente_ativas parameters are unexplained in both the schema and the description.

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: establishments (headquarters and branches) registered at a given CEP, plus the optional narrowing filters. It is clearly distinguishable from a generic filter search such as buscar_empresas_por_filtro, though it never names that sibling explicitly.

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 second sentence gives a real use case (finding shell companies or corporate groups sharing an address), which implies when the tool is valuable. However, there is no explicit when-not guidance and no routing to alternatives like consultar_cnpj or buscar_empresas_por_filtro.

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

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. 'Mostra' implies a passive read, but nothing states freshness, caching, whether it triggers a data load, or permissions. For a zero-annotation tool the disclosure is thin.

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 listing three return facts with no filler. Efficient, though the phrasing is slightly tangled.

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 and no output schema, the description is the only source of information, and it only partially specifies the return shape (month, location, row count). It omits any explanation of what 'consultados' means or what triggers the data set.

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 tool takes no parameters (0 required, 0 optional), so there is nothing for the description to disambiguate. The baseline for a parameterless tool is 4.

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 the tool reveals metadata about loaded Receita files: which month, where they are, and how many rows. That is a concrete output description, but the resource is ambiguous ('arquivos consultados' – which files, from which dataset?) and it offers no differentiation from the ten sibling tools.

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 indication of when to call this tool, what precedes it, or how it relates to alternatives like consultar_cnpj or buscar_empresas_por_filtro. Usage must be entirely inferred.

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

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

With no annotations, the description carries full burden and delivers two valuable disclosures: that matching is by NAME and may return homônimos (a real correctness caveat), and the ~20 queries/minute rate limit. It stops short of auth requirements, empty-result behavior, or pagination, leaving some behavioral gaps.

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?

Four tight sentences with zero padding: purpose first, then the cnpj/sócios behavior, then the homonym caveat, then the rate limit. Front-loaded and each sentence 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?

For an 8-parameter, no-output-schema, no-annotation search tool, the description covers the key behavioral caveats (name matching, homonyms, rate limit) and the main parameter interaction. It omits how nome and cnpj combine when both are absent/present and return-value shape, minor gaps for a list/search tool.

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. The description adds meaning beyond the schema by explaining the cnpj + incluir_socios=true interaction (searches current partners, up to 8) and reinforcing the name-based matching semantics.

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), resource (comunicações processuais: intimações, citações, distribuições) and source (DJEN/CNJ), plus the scope (by party name, grouped by process). This is clearly distinct from the CNPJ/company-oriented siblings, so an agent can select it without opening the 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?

Gives concrete usage context: it documents the cnpj + incluir_socios=true path to search partner names. However, it never names an alternative tool or states when NOT to use this one, so the routing guidance is clear but not exhaustive.

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

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 usefully discloses the recursive traversal behavior and the privacy-relevant detail that individuals are keyed by name + masked CPF. It stays silent on permissions, rate/cost limits, and whether the graph generation is bounded in runtime — a meaningful gap for a potentially large recursive query.

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 sentences, no waste, and the core capability plus its recursion is front-loaded before the identification detail. Every clause 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?

With no output schema and no annotations, the description should carry more of the return/payload story. It describes the graph's composition but not its shape, size limits at the payload level, or behavior on ambiguous names, leaving gaps for an agent that must reason about results.

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 schema already documents cpf, cnpj, nome, max_nos (cap, default 150) and profundidade (1-3, default 2). The description adds no format or syntax detail beyond what the schema states, which is the expected baseline when 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 and resource: it builds ('Monta') the corporate-link graph ('grafo de vínculos societários'), and spells out the traversal semantics — companies, partners, partners' companies, recursively to the requested depth. This recursive scope implicitly distinguishes it from single-hop siblings like empresas_do_socio or socios_em_comum, though no sibling is named explicitly.

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 description tells the agent the two valid entry modes (company via cnpj, person via nome + cpf) and notes cpf is recommended to disambiguate homônimos. It does not, however, say when to prefer this tool over the several graph-adjacent siblings, nor any exclusions or prerequisites.

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

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 discloses the matching logic (same name + same masked document) and that results are limited to partners appearing in more than one company. However, it doesn't mention performance limits (max 50 CNPJs), whether results are paginated, or what the output includes beyond partner identities.

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 sentence that front-loads the core operation and adds the key matching criterion without waste. It is appropriately sized for the tool's complexity.

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 analytical tool with full schema coverage and no output schema, the description is nearly complete. It explains the cross-referencing logic and matching criterion. Minor gaps remain around output format and performance constraints, but nothing critical for correct invocation 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%, with both parameters fully described including formats and default values. The description adds no parameter-specific detail beyond what the schema already provides. Baseline 3 is appropriate when 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 (cruza) and resource (quadro societário de várias empresas) and precisely what it returns: sócios appearing in more than one company. This is distinguishable from siblings like buscar_socio or empresas_do_socio, which operate on a single entity.

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 description implies a multi-company comparison scenario and clarifies the matching criterion (same name and same masked document), which is useful context. It does not explicitly name alternatives or state when not to use it, but the cross-referencing purpose is clear.

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