Babá Certa

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

Annotations already cover safety (readOnly, non-destructive, openWorld), yet the description adds real behavioral context: results are consent-based, ordered by recent publication with no quality ranking, distance is never computed, and an empty list is explicitly distinguished from a technical failure. That last point is an error-semantics disclosure annotations cannot carry.

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, front-loaded with the core action, then ordering, then exclusions. Every sentence adds a distinct constraint or return-behavior fact; nothing is repeated from the schema or annotations.

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 covers everything an agent needs: input source, accepted keys, rejected location forms, ordering semantics, and empty-vs-error behavior. Output format details can safely be left to the output 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 coverage is 100%, so baseline is 3; the description still adds value by stating where the values come from (informadas pela pessoa na conversa) and that cidade means the city without address or neighborhood, reinforcing the exclusion of bairro/CEP inputs. It stops short of format guidance for UF beyond what the schema pattern already gives.

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 (consulta) and resource (perfis públicos consentidos) with the exact scoping keys (cidade e UF). The ordering rule (por publicação recente, sem ranking de qualidade) further pins down what the tool returns, and the sibling calculators (custo/salário) are clearly a different job.

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 explicit when-not constraints: não aceita CEP, bairro ou coordenadas, não calcula distância, não infere localização — directly preventing the most likely misuse of a location-style query. It does not name a sibling alternative, but no sibling overlaps this domain, so the gap is minor rather than misleading.

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 the safety profile (readOnly, non-destructive, closed-world), so the bar is lower, and the description still adds meaningful context: it returns sources and assumptions, and the estimate is neither a salary proposal nor a substitute for a collective agreement. That caveat is exactly the kind of trust/limitation context annotations cannot convey.

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, front-loaded with what the tool computes, then the UF-only edge case, then the disclaimer. No filler; each 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?

For a read-only calculator with an output schema and full param documentation, the description covers purpose, the fallback input mode, and result limitations. Slightly incomplete only in that it does not characterize the basis of the estimate (which statutory components beyond salary/transport are included), though sources are said to be returned.

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 baseline is 3; the description earns an extra point by clarifying the conditional relationship between uf and salarioBruto (UF alone triggers a reference-based example), which the schema's 0-required-parameter structure does not express. Transport and business-days defaults are left to the schema, which is 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?

States a specific verb and resource: computes monthly and annual estimated cost of domestic hiring given gross salary and transport. It is distinguishable in substance from calcular_salario_liquido (employer cost vs. net salary), but it never names that sibling, so the differentiation is implicit rather than explicit.

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 documents a non-obvious invocation mode: passing only UF without salarioBruto yields an example using the state reference from the site's table. That is real guidance beyond the schema. It stops short of 5 because it gives no exclusions or explicit pointer to sibling tools for related calculations.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by naming the returned components (INSS, IRRF, transporte, fontes, premissas) and the non-presumption caveat, but says nothing about rounding, tax-table vintage, or whether results are estimates vs. authoritative figures — significant for a payroll calculation.

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 with no filler: purpose, return contents, and scope caveat, in that order. Efficient and front-loaded, though the return list slightly overlaps the output 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?

An output schema exists, so the description need not detail return values, and annotations cover safety. What remains missing is any note on diasUteisMes defaulting behavior and whether the estimate reflects current tax tables — minor but relevant for an agent deciding trust in the numbers.

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 75%, so most parameters are documented structurally; the description merely names salário bruto, dependentes and vale-transporte, restating the schema. It omits diasUteisMes entirely, which is the one parameter that materially changes the transporte computation, so it adds no meaning beyond the 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?

States a specific verb (estima) and resource (salário líquido mensal de uma babá) plus the inputs that drive it. It does not explicitly differentiate itself from the sibling calcular_custo_baba or mostrar_salario_liquido, which is the only thing keeping it from a 5.

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 closing sentence 'Não presume dados da conta nem interpreta vínculos individuais' establishes a scope boundary, hinting at when the tool is not appropriate. However, it never names an alternative tool or states the positive trigger condition versus calcular_custo_baba, leaving the choice 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 declare readOnlyHint and non-destructive, so the bar is lower, and the description still adds real value: it discloses the interactive-card output, that it recomputes to show current data, and a fallback to the state reference salary labeled as an example when salário bruto is missing. It also explicitly scopes out distance and quality scoring, which prevents misuse.

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 the core action, then prerequisites, then fallback behavior, then exclusions, with no filler. It is slightly dense in one sentence combining query and calculation, but every sentence 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?

An output schema exists and annotations carry the safety profile, so the description only needs to cover prerequisites, fallback semantics and scope limits, all of which it does. The only real omission is routing guidance against the closely related sibling tools.

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 baseline is 3, but the description adds a semantic default not visible in the schema: when salarioBruto is absent it substitutes the current state reference as an explicitly labeled example. That meaningfully changes how an agent should supply or omit the parameter.

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 and resource: queries consented public profiles and computes hiring cost in an interactive card. It is specific about what it produces, but it overlaps conceptually with the siblings buscar_babas_publicas and calcular_custo_baba without naming or distinguishing itself from them.

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 prerequisites (city and UF supplied by the person in conversation) and one explicit exclusion (no distance calculation, no quality ranking), which implies when it applies. However, it never states when to prefer this tool over buscar_babas_publicas or calcular_custo_baba, which is exactly the ambiguity an agent faces with these siblings.

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, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds that it presents an 'interactive card' with 'detailed discounts and adjustable values' and returns 'current calculator data with sources and assumptions', which provides useful context about return content. However, it doesn't clarify whether results are persisted, what the assumptions/fontes actually contain, or how the 'interactive' nature affects agent usage.

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 efficient sentences, each serving a purpose: purpose, requirement, accepted inputs, and return content. Front-loaded with the main capability. No redundancy or filler, though could be slightly more structured (e.g., listing params separately).

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, the description needn't explain return values in depth, and it does mention sources and assumptions. However, for a tool with a very similar sibling ('calcular_salario_liquido'), the description lacks the differentiation needed to select correctly. The 'interactive card' aspect is mentioned but not clarified for agent context.

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 75%, with 'diasUteisMes' and 'valeTransporteDiario' defaults documented in the schema. The description mentions 'dependentes' and 'vale-transporte' as accepted inputs, adding marginal enumeration value, but doesn't explain units, ranges, or defaults beyond what the schema already provides. Baseline 3 is appropriate since the schema does most of 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 pairing ('Calcula e apresenta salário líquido estimado') and describes the output format (interactive card). However, it doesn't differentiate from the sibling 'calcular_salario_liquido', which appears to be a closely related calculation tool. The distinction between calculation-only versus calculation-plus-display is implied but not explicit.

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 says 'Requer salário bruto informado' (prerequisite) but provides no guidance on when to choose this tool over the sibling 'calcular_salario_liquido'. No exclusions or alternatives are mentioned. An agent seeing both tools would need to guess which is appropriate.

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