DataX

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds value they cannot convey: the shape of the response payload (a list of candidates, not a single match) and the commercial cost ('Consome 1 requisição', 'Todos os planos'). It does not mention pagination, result caps, or behavior on zero matches.

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 short sentences with zero filler: capability first, then next step, then cost/availability. Every clause carries information an agent needs, and nothing is buried mid-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?

With no output schema, the description properly compensates by naming the returned fields and indicating a multi-candidate result, and it covers quota and plan scope. For a three-parameter read tool this is nearly sufficient; only edge-case handling (no hits, ambiguous names, approximate-match tradeoffs) 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% and all three parameters are documented there, including the default for buscaAproximada and the UF filter example. The description adds no parameter-level detail beyond implying the name lookup, so the baseline 3 for schema-driven semantics 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?

The description opens with a specific verb+resource ('Encontra pessoas pelo nome') and immediately states what comes back (CPF, data de nascimento, UF), so the agent knows exactly what this call produces. It names the downstream tools ficha_cpf and contatos_cpf, which differentiates it from the other lookup siblings, though it never contrasts itself with pessoas_por_endereco, the closest alternative search mode.

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?

Clear chaining guidance: 'Depois, use ficha_cpf ou contatos_cpf no CPF escolhido' tells the agent this is a discovery step feeding a detail step, which is the primary ambiguity for this family of tools. It stops short of negative guidance, e.g. when to prefer pessoas_por_endereco or what to do when the candidate list is long or empty.

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?

Annotations already cover safety (readOnlyHint=true, destructiveHint=false), but the description adds a non-obvious operational fact that matters for agent decision-making: 'Não consome requisições' — calling this does not burn quota, which is not derivable from the annotations. It stops short of disclosing the shape of the returned series (fields, timezone, whether breakdowns per tool/endpoint are included), and the openWorldHint/idempotentHint=false are left unexplained.

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, zero filler, with the resource and its time window front-loaded and the quota-cost caveat second. Nothing needs to be removed.

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 parameters, the description does a fair job by specifying the aggregation granularity and the quota behavior. It could go further on what the returned daily series actually contains, but for a zero-parameter read-only reporting tool it is close to sufficient.

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?

There are zero parameters, so the schema carries no semantic load the description must compensate for; the baseline applies. The description adds meaningful scope semantics instead — the 30-day window and per-day aggregation — which are fixed behaviors the agent cannot discover from the empty schema.

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 scope: a consumption statement ('Extrato do consumo') covering the last 30 days, aggregated by day. It is clearly distinguishable from the CPF/CNPJ lookup siblings, but it does not distinguish itself from the closest sibling 'limite_do_plano', leaving the agent to infer the difference between plan usage and plan limit.

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 by the words 'Extrato do consumo' — an agent can guess this is for checking recent usage, but the description never states when to call it versus 'limite_do_plano' and gives no prerequisites or exclusions.

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?

Annotations already declare readOnly, idempotent, non-destructive behavior, so the description's job is smaller, and it still adds real value: the per-call request cost, the fact that WhatsApp data appears only when available, and the explicit bounding of the payload to contacts. It does not describe error behavior for an unknown or malformed CPF.

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 short clauses, zero filler, with the scope constraint front-loaded before the cost note. Every sentence carries distinct information an agent needs.

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 usefully enumerates the returned payload (phones, WhatsApp presence, e-mails), so an agent knows what comes back without a second call. Minor gap: no mention of what happens when the CPF has no registered contacts.

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 cpf parameter is already documented as 11 digits with or without punctuation, so the description adds no format or validation detail beyond the schema. Baseline 3 applies because the schema carries the parameter 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 precise verb-and-resource: returns only phones (with WhatsApp flag when present) and e-mails for a given CPF. The clause 'sem o restante da ficha' explicitly separates it from the full-profile sibling ficha_cpf, so an agent can route 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?

'Só os contatos... sem o restante da ficha' gives a clear selection condition against the fuller profile tool, and the cost note ('Consome 1 requisição') helps when the agent is deciding whether a lightweight lookup suffices. The alternative is implied rather than named outright, so there is no explicit 'use X instead' instruction.

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?

The annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true and idempotentHint=false, so safety is covered. The description adds two things the annotations cannot express: the quota cost ('Consome 1 requisição') and the plan gate ('Plano Avançado'), both operationally important for an agent budgeting calls.

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, front-loaded with the resource and its returned fields, then the cost and plan constraint. Every clause carries information; nothing is 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?

For a one-parameter read tool with no output schema, the description covers outputs, quota cost and plan tier, which is nearly everything an agent needs. The remaining gap is that 'recentemente' is never defined - no date window or ordering is stated - so the agent cannot know how fresh the results are.

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 parameter 'limite' is fully documented in the schema (range 1-100, default 20) at 100% coverage, so the schema carries the semantics. The description adds nothing about the limit or ordering, making the baseline 3 appropriate.

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 gives a specific verb and resource ('Lista empresas abertas recentemente') and enumerates exactly what each result carries (CNPJ, razão social, data de abertura, UF). It implies distance from the CNPJ-lookup siblings (ficha_cnpj, socios_cnpj) by being a discovery/list tool, but never names an alternative, so it stops short of explicit sibling 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?

'para prospectar negócios novos' supplies a concrete use case, and 'Plano Avançado' flags an access prerequisite, which is more than most definitions offer. There is no statement of when not to use it or which sibling to pick when a specific CNPJ is already known.

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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new behavioral context: the dataset only holds active companies, the call consumes 1 request, and it is gated to specific plans — cost and coverage caveats an agent cannot infer from annotations.

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 value proposition and the field list come first, followed by the sibling redirect and the cost/plan note; no sentence is filler. The field enumeration is long but each item is informative for deciding whether to call it.

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?

There is no output schema, so the description must convey return values and it does so explicitly through the field list. Missing only failure/not-found semantics for inactive or unknown CNPJs, which is a modest gap for a single-parameter read 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?

With a single parameter and 100% schema description coverage, the schema already explains the 14-character numeric-or-alphanumeric CNPJ and optional punctuation. The description adds no format, normalization, or error-handling detail beyond that, so the baseline 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?

The description names the exact resource (dados cadastrais de uma empresa) and enumerates the returned fields — razão social, situação cadastral, CNAE, porte, Simples/MEI, endereço, contatos, quadro societário — which lets an agent distinguish it from ficha_cpf and socios_cnpj 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?

It explicitly routes the agent away for a subset of data ('Para o telefone e o e-mail de cada sócio, use socios_cnpj') and warns that the base only contains active companies, implicitly defining coverage limits. It stops short of saying what to do when a CNPJ is inactive or not found, so it is clear but not fully 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-annotation context: it consumes 1 credit per call and is available on all plans — relevant for quota-aware tool selection. However it says nothing about behavior on invalid or nonexistent CPFs, data freshness, or rate limits, which is the remaining behavioral 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?

Front-loaded with the payload description, then two short clauses for cost and plan availability; no filler or marketing language. The field enumeration is long but earns its place because no output schema exists. Slightly list-heavy, but every element 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?

For a single-parameter, read-only lookup with no output schema, the description compensates well by enumerating the returned fields and disclosing credit cost and plan coverage. The main omission is failure behavior (nonexistent/invalid CPF) and whether personal data returned has usage restrictions, which an agent might need before calling at scale.

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 'cpf' is already documented as 11 digits with or without punctuation. The description only echoes the lookup key ('pelo CPF') and 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 specific resource and lookup key: registration data for a person by CPF, followed by an explicit enumeration of the returned fields (name, birth date, Receita Federal status, death indicator, phones, emails, addresses). That lets an agent distinguish it from the obvious sibling ficha_cnpj (company counterpart) without opening the schema. It stops short of naming overlapping siblings such as contatos_cpf, so sibling differentiation is only partial.

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 the tool requires a CPF ('pelo CPF') but never states when to pick it over buscar_pessoa_por_nome (search by name) or contatos_cpf (contacts only), nor any precondition such as having a valid or existing CPF. No when-not-to-use condition or alternative routing is given, so the agent must infer selection from tool names alone.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful context the annotations do not carry: 'Não consome requisições' tells the agent the call is free against the quota, which materially affects call strategy. It does not describe the shape or granularity of the returned plan/usage data.

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 short sentences with no filler, and the useful part (what it returns, that it costs nothing, that it is a good first test) is front-loaded. Nothing is repeated from the title or schema.

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 zero-parameter, read-only introspection tool with no output schema, the description covers what comes back (plan plus daily and minute usage) and why to call it. Only the overlap with the 'consumo_do_plano' sibling remains unaddressed.

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 zero parameters, so the schema imposes nothing to explain and the baseline is 4. The description correctly implies no input is required by framing the tool as a pure introspection call.

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 shows the key's plan and how much of the daily and minute quota is already consumed. It is clear on its own, but it never distinguishes itself from the sibling tool 'consumo_do_plano', which sounds like it covers overlapping ground, so an agent cannot fully disambiguate from the text alone.

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 an explicit usage context: 'Bom primeiro teste para confirmar que a chave funciona' tells the agent to use it as an initial key-validation call. It stops short of naming when to prefer 'consumo_do_plano' instead, so the routing between the two quota-related siblings is left to inference.

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?

Annotations already cover readOnly, idempotent, non-destructive and openWorld, so the description correctly spends its space elsewhere: the cost ('Consome 1 requisição'), plan availability ('Todos os planos') and the server-side rejection of generic queries. These are real behavioral facts an agent cannot see in the annotations or schema; only result-set size/pagination behavior is left unstated.

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 short sentences with no filler: purpose first, then valid input shapes, then the rejection rule, then cost and plan. Every sentence carries a decision-relevant fact and nothing is repeated from the schema.

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 six-parameter, zero-required tool with no output schema, the description covers all the combination rules, the credit cost and plan gating, and names the returned fields. It stops short of describing result volume or paging limits, which is the main remaining unknown for an address-scoped person lookup.

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 meaning the schema does not: cep works standalone, logradouro must be paired with cidade and estado, and numero/bairro act as narrowing filters rather than requirements. That 'restrict the result' framing is distinct from the schema's bare 'Opcional' labels, so it earns above baseline.

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 names a specific verb and resource ('Encontra as pessoas') and pins the lookup key to a CEP or a full address, plus the returned fields (nome e CPF). This makes it self-evidently distinct from name-based siblings such as buscar_pessoa_por_nome or ficha_cpf, since the input axis (address) is stated up front.

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 explicit valid input combinations ('Informe cep, ou logradouro com cidade e estado') and an explicit negative rule ('Buscas genéricas (só a cidade ou só o estado) são recusadas'), which is exactly the when-not guidance an agent needs. The gap is that it never points to an alternative tool for the name-only or broad-city case, leaving the routing decision to inference.

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?

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld). The description adds genuinely new behavioral context: it costs 1 request against the plan quota and is available on all plans, which is exactly what an agent weighing cost needs.

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 short sentences, zero filler, front-loaded with the purpose before the cost and plan notes.

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 one parameter and no output schema, the description usefully states the return shape (name and CPF) plus the credit cost, which is what an agent needs before calling. It stops short of describing the not-found behavior or response format.

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?

There is a single required parameter with 100% schema description coverage, so the schema already carries the meaning. The description adds nothing about email format or normalization, so 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?

"Descobre a pessoa dona de um e-mail: nome e CPF" names a specific verb (reverse lookup) and resource (email) and even states the returned fields. It is clearly distinguishable from siblings like buscar_pessoa_por_nome or reverso_telefone, though it never names an alternative 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?

Usage is implied: you have an email and want the owning person's name and CPF. There is no explicit when-to-use versus the sibling name-search or phone-reverse tools, and no guidance on what to do when the lookup fails.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely new operational context: the call consumes 1 request and is available on all plans, which matters for an agent managing quota against siblings like consumo_do_plano and limite_do_plano.

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 short sentences, zero filler, and the payload (what you get back) is front-loaded before the cost and plan notes. Every sentence carries distinct 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 output schema, the enumeration of returned fields (nome, CPF, operadora, WhatsApp) is exactly the right compensation, and the cost/plan notes complete the picture for a one-parameter lookup. Only the failure/not-found behavior is left unaddressed, a minor gap for a tool this simple.

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 the DDD format, optional +55 and punctuation tolerance. The description adds nothing about the numero parameter, 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 and resource ("Descobre o titular de um telefone") and enumerates exactly what comes back: nome, CPF, operadora, WhatsApp status. The phrase "de um telefone" implicitly distinguishes it from reverso_email and ficha_cpf, which key off other identifiers, but the differentiation is left to inference rather than stated.

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 by the input type — an agent can infer this is the phone-number reverse lookup. There is no explicit when-to-use guidance, no mention of when to prefer reverso_email or ficha_cpf, and no statement about what happens for a number not in the base.

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?

Beyond the readOnly/idempotent/openWorld annotations, it discloses the real operational cost: 1 unit of the daily limit per partner returned, tracked in unidadesConsumidas, plus 1 hit on the per-minute limit, and which plans grant access. It also enumerates exactly what is returned, so the agent knows the payload shape without an output schema.

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 sentences that front-load the purpose, then the output fields, then the cost and plan constraints. The parenthetical about partner-vs-company contact is the only long clause and it earns its place by preventing a common misread.

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 single-parameter lookup with no output schema, the description covers input, returned fields, quota consumption, and plan eligibility. Nothing an agent needs in order to decide to call it or to interpret the cost 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% and the cnpj parameter is fully documented, including punctuation tolerance and alphanumeric support, so the description adds nothing beyond 'Recebe um CNPJ'. Baseline 3 is appropriate since the schema carries the parameter 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 (receives a CNPJ, returns) and a precise resource (sócios pessoa física with nome, CPF, qualificação, telefones, e-mails), and explicitly distinguishes its output from the company-level phone in the Receita cadastro, which implicitly separates it from ficha_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?

The 'o contato de cada sócio, não o telefone da empresa' clarification steers the agent toward this tool rather than the company record, and the plan list signals eligibility constraints. It never names a sibling tool or states an explicit exclusion, so it stops short of full when/when-not routing.

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