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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds genuinely new operational context: it requires META_APP_ID and META_APP_SECRET in the MCP environment and uses an app token. That credential prerequisite is the kind of thing an agent cannot get from structured fields.

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, front-loaded with what is returned and the endpoint, then credentials, then the diagnostic scenario. Tight overall, though the aside about a real proven cause is slightly more narrative than 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 correctly explains what is returned (callback URL and signed fields) and which subfields matter when checking coexistence (smb_message_echoes, history, smb_app_state_sync). Combined with the stated credential requirements, an agent has enough to call it correctly and interpret the result.

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 optional parameter with 100% schema description coverage and an enum, so the schema fully documents it. The description adds nothing about response_format, which is acceptable given the coverage, but leaves it at the baseline rather than earning more.

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 ('Mostra a URL de callback e os campos assinados do app') plus the underlying endpoint GET /{app_id}/subscriptions, which is concrete evidence of what the tool returns. It does not, however, distinguish itself from the sibling wa_check_webhook, so an agent must infer that this one is app-level and the other WABA-level.

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 a concrete triggering symptom ('a mensagem não chega no sistema') and even names the observed failure signatures (callback vazio, campo 'messages' faltando), plus a secondary use case for coexistence setups. It stops short of explicitly routing the agent away from wa_check_webhook or wa_check_coexistence, so no exclusions are stated.

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, but the description adds real substance: the exact upstream endpoint queried, the field combination that must hold for coexistence, and the fact that throughput is fixed at 20 mps under coexistence. Missing only the concrete response shape beyond the two flag semantics.

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 blocks: what it proves and the field logic first, then the usage trigger. The endpoint spec and the 20 mps note are compact and each carries information an agent needs; 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?

For a two-optional-param read-only diagnostic with no output schema, the description covers what is queried, how to read the result, and when to run it. The only gap is the exact returned payload/error behavior if the number isn't on the Cloud API at all.

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 both parameters are self-documented, including the fallback to META_PHONE_NUMBER_ID and the response_format enum. The description adds no parameter-level detail (e.g., which phone_number_id to pick, when json is preferable), 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?

Names the specific check (Meta's official coexistence test) and even the underlying call GET /{phone_number_id}?fields=is_on_biz_app,platform_type, plus the interpretation rule (is_on_biz_app=true + CLOUD_API). That makes it clearly distinct from siblings like wa_check_waba or wa_list_phone_numbers, which inspect different objects.

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 says to use it after completing the Embedded Signup ('coexistencia' phase) or to prove a number is NOT in coexistence, which is a clear positive and negative trigger. It doesn't name a fallback sibling for related diagnostics, so it stops short of full alternative routing.

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 read-only, idempotent, and non-destructive behavior, so the bar is lower; the description still adds real value by disclosing that the token is never displayed ('Nunca mostra o token') and by implying an external call to Meta's debug_token endpoint. It does not mention rate limits or failure modes, which keeps it below a 5.

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, front-loaded with what is validated before the when-to-use triggers. Every clause carries information; nothing is redundant with 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?

With no output schema, the description compensates by listing what the check reports (type, expiry, permissions, account access) and the safety guarantee about the token. What the exact response shape looks like is left implicit, but an agent has enough to call it correctly.

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 optional parameter (response_format) with an enum and 100% schema description coverage, so the schema fully documents it. The description adds nothing about the parameter, which is acceptable at this coverage level but earns only the 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?

States a specific verb and resource ('Valida o META_ACCESS_TOKEN com debug_token') and enumerates exactly what is verified: SYSTEM_USER status, expiry, permissions, and accessible WhatsApp accounts. This enumeration distinguishes it from siblings like wa_check_waba or wa_check_coexistence without the agent needing to open 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?

Gives two concrete invocation triggers: immediately after token generation (naming the 'usuario-sistema-token' phase) and when 'Session has expired' appears. No explicit exclusions or named alternatives are given, so it falls just short of the top band.

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 read-only, idempotent and non-destructive behaviour, so the description's value-add is the failure contract: error #100 and its two distinct causes (wrong WABA ID versus missing user access). That is genuinely useful pre-call context, though it stops short of describing output shape or the markdown vs json difference.

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, front-loaded with what is read before the failure condition. The phase-name parenthetical is slightly opaque jargon, but nothing is redundant.

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 correctly compensates by listing the returned fields, and the safety/param burden is carried by annotations and schema respectively. Only the shape of the #100 failure payload 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?

Schema coverage is 100% and both parameters are fully documented, including the META_WABA_ID fallback and the response_format enum meanings. The description adds nothing beyond naming the WABA ID as the identity input, 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 verb (reads) and resource (WABA) and enumerates the fields it surfaces: name, currency, account review status, business verification status. That makes it clearly distinct from siblings like wa_list_phone_numbers or wa_check_token, 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 parenthetical '(fases ids e usuario-sistema-token)' implies where this fits in a guided diagnostic flow, but it never says plainly 'use this when X, use wa_check_token instead when Y'. Usage is inferred rather than stated.

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 genuine context beyond that: what an empty result implies operationally and that callback URL/subscribed fields are deliberately not returned. It does not describe the shape of the returned app objects.

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: the operation first, the failure interpretation second, the scope exclusion last. No filler and nothing an agent must read twice.

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 does supply the key return semantics (a list of subscribed apps, empty means no delivery) and warns about what is absent. A brief note on what each returned app entry contains would fully close the gap for a diagnostics 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 description coverage is 100%, including the waba_id pattern and the META_WABA_ID fallback plus the response_format enum, so the schema carries the parameter burden. The description adds no parameter-level meaning beyond what is already documented.

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 ('Lista os apps inscritos na WABA') and even cites the underlying endpoint GET /{waba_id}/subscribed_apps, so the operation is unambiguous. It also draws a scope boundary by saying callback URL and subscribed fields do not appear here, though it never names the sibling tool (wa_check_app_webhook) that would cover 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?

Gives a clear diagnostic context for use: an empty result means Meta is not delivering events for this account, which is exactly the 'message sent but never arrived' symptom. It stops short of explicitly routing the agent to wa_check_app_webhook or wa_subscribe_webhooks as the follow-up for missing callback configuration.

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/destructiveHint=false, so safety is covered; the description adds real behavioral context beyond them: per-item ✅/⚠️/❌ output plus a 'next phase' verdict, the waba_id resolution fallback, and an honest API limitation. It does not mention that fanning out across many Graph endpoints may be slower or rate-limited, which is the remaining 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?

Three short paragraphs, front-loaded with what is checked, then the use-case framing, then the omission fallback and limitation. The checklist enumeration is long but each item earns its place by telling the agent what will be reported.

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 carries the burden of describing returns — it does (status symbol per item plus the next phase needing attention). Zero required parameters, fallback resolution, and an explicit coverage limitation are all covered; nothing needed to call it 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 coverage is 100%, so the baseline is 3, but the description adds semantics the schema lacks: if waba_id is omitted it falls back to META_WABA_ID or the single WABA visible to the token (the schema only mentions META_WABA_ID). response_format is left to the schema, which is adequate.

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 enumerates exactly what the checklist covers (token, WABA, moeda, verificação, números, webhook, templates), which immediately separates this aggregate diagnostic from the granular wa_check_token / wa_check_waba / wa_list_phone_numbers / wa_check_webhook siblings. An agent knows precisely what it gets 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 explicit entry-point questions it answers ('em que ponto estou?' and 'por que a mensagem não sai/chega?') and one clear exclusion with a redirect (payment method not covered, check the billing hub instead). It stops short of saying when to prefer the individual check tools over this aggregate, so a 4 rather than 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?

The annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is handled. The description adds that no input is required beyond the configured token, that results come from the accounts the token is entitled to see, and that a missing account indicates a System User assignment problem. It does not cover pagination or rate limits, but the added context is meaningful.

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 paragraphs. The main capability and its payoff (correct IDs for the system) come first, and the troubleshooting note is separated for easy scanning. No sentence 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?

There is no output schema, so the description must convey what comes back, and it does: the WABA accounts accessible to the token, their phone numbers, and the correct IDs. It also covers the zero-parameter invocation and the common failure mode. The only minor gap is the lack of guidance on the response format choice.

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 only one parameter, response_format, whose enum and meaning are already fully documented in the schema (100% coverage), including the markdown-vs-json distinction. The description adds nothing about it, 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?

The description gives a specific verb and resource: it lists the WhatsApp Business accounts (WABAs) that the token can access, plus each account's phone numbers and the correct IDs. It also states the tool's distinct value, resolving confusion between the WhatsApp Manager ID and the WABA API ID. It never names an overlapping sibling such as wa_list_phone_numbers or wa_check_waba, so the agent has to infer which tool is the right one.

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 the tool is the discovery step for the 'ids' phase: it starts from a token and yields the IDs needed to configure the system. It also gives a concrete troubleshooting condition: if the target account is missing, the System User was not assigned to it. It does not explicitly say when to prefer wa_list_phone_numbers or wa_check_waba instead.

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, idempotent, non-destructive), so the description only needs to add behavior beyond that. It does: it discloses the no-match fallback ('Retorna vazio com sugestões se nada bater'), which is the failure mode an agent most needs to know about. It stays silent on result size or ranking when multiple errors partially match.

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 purpose, then coverage, then examples, then the fallback note — a sensible order where every block earns its place. The parenthetical list of example codes is slightly sprawling but functions as matchable evidence rather than 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, so the description carries the return contract, and it does: meaning, cause, recommended action, and the related path phase, plus what happens on no match. For a one-parameter lookup tool this leaves no operational 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond it: the single `query` accepts either a numeric code or a screen-text fragment, demonstrated with one example of each. That is exactly the ambiguity an agent would otherwise stumble on.

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 ('Traduz um erro da Meta/WhatsApp') plus the exact output shape (significado, causa, o que fazer, fase do caminho). That distinguishes it from diagnostic siblings like wa_diagnose and reference siblings like wa_glossary without opening their schemas.

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 two worked examples ('Deu 131037 no envio' -> query="131037") make the trigger condition concrete, and the coverage note (27 errors, both real-world and documented) tells the agent where the tool's knowledge stops. It never explicitly contrasts with wa_diagnose or wa_check_waba, so the agent must infer the boundary.

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 closed-world, so the safety profile is fully covered and the description only needs to add content-level context — which it does by listing the term categories. It says nothing about the shape, length, or language of the returned definitions, leaving the agent to discover that on invocation.

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: the first front-loads what is covered, the second gives the trigger condition. The trailing '…' efficiently signals the term list is illustrative rather than exhaustive, 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?

For a zero-parameter glossary with full annotation coverage and no output schema, this is close to sufficient — the agent knows what terms and when to call it. Only the absence of any signal about return content or relationship to the other guide tools keeps it from being 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?

Zero parameters, so there is no parameter surface to explain and the description correctly spends no words on one. The listed term families give an implicit sense of the lookup scope the tool will resolve.

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 ('Define os termos') and enumerates the exact concept families covered — WABA, Phone Number ID, Usuário do Sistema, janela de 24h, tier — so an agent knows the tool's scope without opening the schema. It does not, however, distinguish itself from conceptual siblings like wa_guide_overview or wa_guide_search, which could plausibly answer similar questions.

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 trigger: 'Use quando o usuário misturar IDs ou conceitos', which is the exact situation an agent would be in after a confusing diagnostic. No when-not conditions or named alternatives are provided, despite overlapping guide tools in the sibling set.

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/local, so the safety profile is covered. The description adds genuine behavioral content the annotations cannot: what the returned phase contains and the structured pitfall format (sintoma → causa → o que fazer), which tells the agent what it will actually read.

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 return summary, then the valid ids, then examples — a scannable structure with no filler. The phase list partially duplicates the schema enum, a minor redundancy, but it keeps the description self-contained.

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 enum parameter and no output schema, the description carries the burden of describing returns and does so (steps, completion markers, pitfalls). An agent can call it correctly from this alone; only the exact serialized shape remains 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?

Schema coverage is 100% and the enum is fully enumerated in the schema, so the baseline would be 3. The description goes beyond by mapping natural-language questions to specific phase_id values, which is real intent-to-parameter guidance absent from 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 and resource ('Devolve uma fase do caminho') and details the payload: steps tagged VOCÊ/AUTOMÁTICO/JUNTOS, completion criteria, and pitfalls in symptom→cause→action form. That content shape distinguishes it from wa_guide_overview or wa_guide_search, 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 enumerated phase list plus three worked question→phase_id examples give clear guidance on when to reach for this tool. It stops short of stating exclusions (e.g. 'use wa_guide_overview for the whole roadmap'), so it is clear context without explicit alternatives.

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 openWorldHint=false, so the safety profile is covered; the description reinforces it with 'Não acessa a rede'. It also signals that this is a static orientation document (fixed 12-phase structure, defined role split) rather than a query against the user's account, which helps the agent reason about freshness and scope. It stops short of describing output size or shape, so a 4 rather than 5.

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: what it contains, when to call it plus the follow-up tool, and the no-network constraint. The payload (12 phases, role split) is front-loaded and 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?

For a zero-parameter, read-only static reference tool with no output schema, the description covers content, invocation timing, the sibling to escalate to, and the no-network property. Nothing an agent needs in order to call it 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?

The tool takes zero parameters (additionalProperties: false, empty properties object), so there is no parameter semantics to explain — the baseline of 4 applies. The description correctly says nothing about inputs, matching 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?

The description names a concrete artifact (the complete path to getting a number, including a virtual one, on Meta's official WhatsApp API) and enumerates what it contains: the 12 phases in order, who executes each (you / automatic / together), and what the agent never does. That is far more specific than the vague title 'Visão geral do caminho' and clearly separates it from the detail-oriented wa_guide_get_phase.

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 states an explicit trigger condition — use at the start of any conversation about 'conectar número', 'disparos pela API oficial' or 'número virtual' — and names the follow-up tool wa_guide_get_phase for deeper detail. Both when-to-use and the alternative are spelled out, leaving nothing 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 readOnly/idempotent/non-destructive, and the description adds real behavioral detail beyond them: matching is AND across all words, accent- and case-insensitive, and a tag-only/empty call returns the tag index with phases and errors per tag. It does not describe the shape of ordinary search hits.

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 core behavior and the fallback case before any enumeration, and the examples each earn their place by disambiguating query vs. tag. The inline tag list duplicates the schema enum almost verbatim, which is the only real waste.

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 must carry return-value context, and it at least specifies the no-arg response (tag index with phases and errors). It leaves the fields of a normal search result unstated, a minor gap for a zero-required-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?

Schema coverage is 100%, so the baseline is 3; the description goes beyond it by explaining the matching semantics of `query` (all words must appear, accent/case folding) and that `tag` is supplied without the '#'. That is meaning the schema's "Palavras a procurar" does not convey.

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 ("Busca") and a precise resource scope: all guide steps, pitfalls and errors, searchable by free text and/or tag. It implicitly distinguishes itself from the phase-scoped siblings (wa_guide_get_phase, wa_guide_overview) by covering the whole guide, but 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?

The three worked examples map realistic user intents ("Onde fica o Phone Number ID?", "Tudo de coexistência") to concrete parameter choices, which is strong routing guidance, and the no-argument fallback behavior is stated. It stops short of saying when to prefer wa_guide_get_phase or wa_explain_error over this search.

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, and openWorldHint, so the safety profile is covered. The description adds genuinely useful domain context not in the annotations: which status values appear (CONNECTED, CLOUD_API), and the causal link between name_status PENDING_REVIEW and error 131037. It does not mention rate limits or result volume, so it stops short of a 5.

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?

It is a single front-loaded sentence that leads with the resource and then the payoff fields. The enumerated field list is dense but every item is informative; only the parenthetical about 131037 makes the sentence long enough to be slightly unwieldy.

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 only two optional parameters, full schema coverage, and annotations covering mutability/safety, the description supplies the remaining piece an agent needs: what the returned records contain and how to interpret the critical status field. No output schema exists, and the field enumeration compensates for that adequately.

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 both waba_id (including the META_WABA_ID fallback) and response_format (markdown vs json) are already fully documented in the schema. The description adds no parameter-level meaning beyond that, which is the expected baseline of 3 when the schema carries the burden.

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 ('Lista os números da WABA') and then enumerates exactly which fields come back (Phone Number ID, status, verification, platform, display name, quality, messaging tier), so an agent knows precisely what this tool retrieves. The resource (phone numbers of a WABA) cleanly separates it from siblings like wa_list_templates or wa_check_waba.

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 by the enumeration of diagnostic fields (name_status PENDING_REVIEW → error 131037), which hints this is the tool to reach for when send failures occur. However, there is no explicit statement of when to use this versus wa_check_waba, wa_discover_ids, or wa_diagnose, and no exclusions or prerequisites are given.

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 safe-read profile (readOnly, idempotent, non-destructive), so the bar is lower; the description still adds real value by disclosing pagination behavior and the specific failure mode (#200 = System User lacking 'Message Templates' permission), which is diagnostic context not present in any structured field.

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 is listed and what fields come back, then pagination, then the error mapping. No filler and nothing buried.

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 carries the burden of describing return shape and does name the key fields; it also explains pagination and a common auth error. Minor gaps remain around page-size limits and whether results are filtered by status, but nothing needed to call it 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 coverage is 100%, so all four parameters are already documented including the META_WABA_ID fallback and the enum for response_format. The description only restates the limit/after pagination pair, adding no syntax or format detail beyond the schema — baseline 3.

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?

Specific verb + resource: lists WABA templates and names the returned attributes (status, category, language). It does not explicitly contrast itself with the sibling listing tool wa_list_phone_numbers, but the resource is unambiguous.

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 — an agent can infer it should call this to inspect templates and paginate with limit/after. There is no explicit when-to-use / when-not-to-use guidance or routing to alternatives such as wa_explain_error or wa_diagnose.

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 only say it is not read-only / not idempotent / open-world. The description adds what the tool actually does in the world: it sends a real paid message, returns the wamid, and real delivery or failure (error codes 131037, 131042) surfaces only asynchronously in the status webhook. That is exactly the kind of consequence an agent cannot infer from the 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?

Two short paragraphs: the first front-loads the action and the cost/phase constraint, the second covers the confirmation gate and the async delivery caveat. No sentence 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?

There is no output schema, and the description compensates by stating the return value (wamid) and warning that delivery confirmation is not in the response. Combined with the confirmation gate and error-code routing, an agent has everything needed to call it safely.

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 still adds the operational rule that confirm must be true and only after the user confirms, plus the recipient format and the hello_world / en_US defaults. The mention of phone_number_id falling back to the META_PHONE_NUMBER_ID env var lives in the schema rather than the description, so it stops short of 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 concrete verb and resource ('ENVIA uma mensagem real de template pelo número') and immediately flags the cost implication, which distinguishes it from every read-only sibling like wa_list_templates or wa_diagnose. No sibling sends messages, and the description makes that uniqueness 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?

Gives an explicit precondition chain: only in the 'primeiro-envio' phase, to one of your own contacts, and only after wa_diagnose returns without FAIL – naming the sibling tool that gates it. It also implies when-not by restricting scope to test sending rather than bulk messaging.

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 annotations, the description discloses that this mutates Meta-side configuration, that confirm=true is required only after the user consents, and that the optional callback override requires the URL to answer the handshake with verify_token. "Repetir é inofensivo" reinforces idempotentHint=true with plain-language context. It does not cover response shape or any failure modes.

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 the endpoint and the effect, then the optional override, then the confirmation gate. Every clause carries information an agent needs; 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 non-destructive, idempotent mutation with full schema coverage and no output schema, this covers purpose, prerequisite, optional-parameter coupling, and repeat safety. The main remaining gap is what the call returns or what indicates success.

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 real meaning: it explains the override_callback_uri + verify_token pairing and the shared-app scenario that motivates it, which goes beyond the field-level notes. waba_id's META_WABA_ID fallback is left to 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?

Names a specific verb+resource (POST /{waba_id}/subscribed_apps, subscribing the token's app to a WABA) and states the concrete effect: Meta will deliver this WABA's events to the app. It does not differentiate itself from siblings like wa_check_app_webhook or wa_check_webhook, which is the only thing keeping it below 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?

"Sem isso nenhuma mensagem recebida nem status chega" gives a clear condition for when the tool is required, and the confirm-after-user-agreement prerequisite is stated explicitly. It stops short of naming alternatives (e.g., checking existing webhook state first), so no exclusions are provided.

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