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

With no annotations, the description carries the full behavioral burden. It usefully discloses the key side effect (the amount is returned to the balance) and the precondition, but says nothing about idempotency, error behavior when the precondition is violated, or whether the cancellation is permanent.

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 with zero waste; the scope condition is stated before the failure condition, keeping the important information front-loaded.

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 mutation with no annotations and no output schema, the description covers the essential semantics: the refund side effect and the SMS precondition. It falls short only on failure/idempotency behavior, which an agent could otherwise need.

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 single `id` parameter is already documented in the schema with its type and constraint. The description adds no format, source, or lookup detail beyond the schema 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 (cancela) and resource (ativacao) and adds the decisive scope constraint that it only applies before an SMS arrives. This cleanly separates it from siblings like complete_activation and wait_for_sms without ambiguity.

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 an explicit when-it-works condition ("ainda nao recebeu SMS") and an explicit when-it-fails condition ("Nao funciona depois que o codigo chegou"). It does not name the alternative tool to use once the code arrives, which is the only thing keeping it from a 5.

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 does add a genuine behavioral fact beyond the name: the call is optional but frees the number earlier, which hints at a resource-release side effect. It omits error behavior, idempotency, and what happens if the activation is already completed.

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?

One compact sentence with the action front-loaded and the optional/benefit nuance appended. Every clause earns its place; nothing is padded.

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 mutation with no annotations and no output schema, the description covers the essential behavior and the optional nature of the call. It still leaves the agent without error semantics or confirmation of what completion changes beyond freeing the number.

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% with a single documented 'id' parameter, so the schema already carries the parameter meaning. The description adds nothing about the parameter, which is acceptable given full coverage but not additive.

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: marking an activation as complete. It is distinguishable from siblings like cancel_activation and get_activation by the outcome described, though it never explicitly contrasts itself with 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?

"Depois de usar o codigo" gives a timing condition for use, and "Opcional" signals it is not mandatory. However, it offers no guidance on when to prefer cancel_activation or what happens if the activation is never completed, leaving the alternatives entirely 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?

With no annotations, the description carries the full burden and does disclose meaningful behavior: the possible status values (waiting_sms, sms_received, cancelled, expired), the fact that code/SMS text only appear once the SMS arrives, and the expected polling cadence. It doesn't address read-only safety, auth requirements, or error behavior, but for a status-read tool the state model is the key behavioral information.

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, front-loaded with what is returned, then the enum values, then the polling advice. No filler or restated name/title.

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?

No output schema and no annotations, so the description must imply the return shape — and it does by naming status, telefone, codigo and SMS text. It is complete enough to call correctly; only the error/not-found behavior is left unspecified.

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?

Only one parameter exists and schema description coverage is 100%, so the schema already documents 'id' (including its origin in request_number). The description adds no parameter detail, which is the expected baseline when the schema does the work.

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+resource ('Situacao atual de uma ativacao') and enumerates exactly what the caller gets back: status values, phone, code and SMS text. It also names the sibling it differs from (wait_for_sms), so an agent can separate it from the other nine activation 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?

It gives concrete operational guidance ('Consulte a cada 5-10 s') and routes to an alternative ('prefira wait_for_sms'). It stops short of stating the condition under which polling beats waiting, but the preference hint is explicit enough to steer tool choice.

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 usefully discloses that number purchases are debited from this balance, which gives the agent meaningful domain context, but it says nothing about read-only vs mutating semantics, currency formatting, or what the response contains.

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 core answer (current balance, currency) before the supplementary domain note. No wasted words.

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 tool with no output schema, the description covers what is returned and its currency. Only the concrete return shape (numeric value, formatting) is left unspecified, which is a minor gap.

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 there is nothing for the description to disambiguate; the baseline of 4 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 verb-equivalent: it returns the current account balance at Numero Virtual, in BRL. No sibling tool deals with balance, so the purpose is unambiguous even without 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?

Usage is implied rather than stated — an agent would naturally call this to check funds before request_number. There is no explicit when-to-use statement, no mention of prerequisites, and no named alternatives, though none of the siblings overlap.

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, and it delivers: rate limit (6 queries/minute), result stability, and the recommendation to store the result. It does not describe the response shape, but the explicit operational constraints are strong contextual disclosure.

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, front-loaded with the purpose before the code-usage and caching/rate-limit notes. Zero 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?

Complete enough for a zero-param read-only list tool: purpose, output field guidance, rate limit, and caching advice. It lacks any response structure description, minor for a no-output-schema tool but the field-level guidance partly covers it.

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?

Zero parameters, so baseline is 4. The description adds cross-tool semantics by explaining that the returned "code" field is ISO format and should be passed to other tools, which is useful despite there being no input params.

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: lists countries that have numbers in stock, plus a per-country service count. That is concrete beyond the title, though it never names or distinguishes itself from siblings like list_services.

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 real usage guidance: tells the agent to reuse the "code" field in other tools, and warns to cache the result because it changes little. No explicit when-not-to-use or alternative tools are named, but context is clear.

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 well: it discloses a hard rate limit (6 requests/minute), the sort order, the price unit (BRL cents), the existence of nested supplier options, and the output field names serviceId/apiId. It is a read-only listing so no destructive/permission caveats are needed, though pagination behavior beyond the limit param is 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?

Front-loaded with what is returned, followed by the ID-to-request_number linkage, the search tip, and the rate limit. Every sentence carries information, though the opening sentence is long and stacks several facts (ordering, price unit, supplier options) into one breath.

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 supplies the return-shape essentials (serviceId/apiId, price in cents, supplier options, ordering) plus the cross-tool contract with request_number. Only limit/pagination semantics and any country-availability nuances remain implicit.

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 limit, search, and country are already fully documented in the schema (baseline 3). The description adds only that search exists as a way to cope with the large Brazil list; it adds no format or default details beyond what the schema already carries.

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?

Names a specific resource (servicos/serviços com estoque por país) and adds distinguishing detail: sorted cheapest-to-most-expensive, prices in BRL cents, and per-service supplier options. An agent can immediately tell this apart from get_balance, list_countries, or request_number.

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 clear context for when the tool is needed and how to navigate it (use "search" to find a service by name given the ~700-item Brazil list). It also states downstream usage: the returned serviceId/apiId are the values passed to request_number. No explicit exclusion rules are given, but the routing guidance is concrete.

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: it discloses that the balance is debited immediately (a real cost side effect), the ~20-minute lifetime of the number, and that cancellation refunds the value. It also tells the agent what the call returns (activation id and phone).

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 tightly packed sentences: action and cost first, then the return value and next step, then the time limit and refund path. No sentence is redundant and the most decision-relevant facts (cost, expiry, refund) are front-loaded.

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 and no annotations, so the description must cover the return and safety profile itself — and it does, naming the returned activation id and phone plus the expiry/refund behavior. Nothing an agent needs to invoke this correctly 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%, so the schema already documents all four parameters (ddd, apiId, country, serviceId) and their defaults. The description adds no parameter-level detail beyond the schema, which is the baseline 3 case.

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 ('Compra um numero virtual') plus the exact purpose (receber o SMS de verificacao). It also names what is returned and routes the agent to siblings, so it is distinguishable from the other activation tools at a glance.

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 follow-up routing: use wait_for_sms or get_activation to read the code, and cancel_activation if the SMS never arrives. The ~20-minute validity window tells the agent when the number expires, which is exactly the condition that selects the cancel path.

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. It usefully discloses the precondition that the downstream service must allow resending, but says nothing about failure modes, cost implications, rate limits, or whether the original activation state changes.

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 action and then the use condition; there is no redundant or filler text.

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 action with no output schema and no annotations, the description covers what it does, the precondition, and when to invoke it. It is nearly sufficient, missing only outcome/failure behavior for a resend request.

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?

Only one parameter (id), and schema description coverage is 100% ('ID da ativacao'), so the schema already documents it fully. The description adds no format, range, or sourcing detail beyond the schema, 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?

States a specific verb+resource: requesting a fresh SMS from the provider for the same activation. It is clearly distinguishable from siblings like request_number, wait_for_sms and cancel_activation, though it does not explicitly name any sibling for contrast.

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?

"Use se o primeiro nao chegou" gives a clear triggering condition, and the parenthetical narrows it further to cases where the service permits a resend. No alternative tool is named (e.g. wait_for_sms first), so it stops short of explicit when-not guidance.

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 well: it discloses the polling interval (5s), timeout default/max (60/300), the ~20 min validity of the number, the retry semantics, and the true/false return flag. It omits auth requirements and rate limits, but for this operation the behavioral profile is largely complete.

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: the polling/timeout behavior is front-loaded, followed by the return and retry guidance. Every clause earns its place with 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?

There is no output schema, and the description reasonably summarizes the return (the activation with codigo_chegou true/false), plus retry and alternative paths. Slightly more detail on the full return shape would make it fully complete, but an agent has enough to call and interpret it.

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 both parameters are already documented. The description restates the 60s default and 300 max from the schema without adding format or syntax beyond what the schema provides, 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 behavior: polls the activation every 5s until the code arrives or time runs out. It also names siblings (resend_sms, cancel_activation) as alternatives, so an agent can distinguish this blocking-wait tool from the fire-and-check siblings.

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 clear when-to-use context ('if it hasn't arrived, call again') and names the two alternatives. It doesn't spell out the exact conditions that favor resend_sms over re-calling this tool, so it falls just short of fully explicit routing.

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