WasapFlow Bridge

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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the safety profile is known. The description adds a genuinely non-obvious protocol detail — irreversible endpoints require {"confirm": true} in the body — which is not visible anywhere in the schema. It says nothing about auth requirements, rate limits, or how errors/unknown paths surface, which matters for a fully open passthrough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with no filler: scope first, then the hidden protocol requirement, then the user-confirmation guardrail. The ordering puts the highest-value information (when to use this instead of siblings) at the front.

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 dangerous open-world passthrough this covers the essentials: scope, path discovery route, the confirm flag, and a human-in-the-loop rule. Remaining gaps are what a caller gets back and how failures on non-existent paths behave (there is no output schema to carry that), which is a modest omission rather than a blocking one.

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 80%, so the baseline is 3; the description earns above that by documenting a body sub-key ('confirm': true) that the free-form 'body' object schema cannot express. It also adds the /bridge/v1 path convention context, though the waba_id and query semantics are left entirely 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?

States a specific verb and resource ('Call any WasapFlow Bridge endpoint') and immediately bounds the scope to endpoints 'not covered by the other tools', which is exactly the distinction an agent needs against the 14 siblings. It also names a sibling (bridge_docs_search) as the place to resolve paths, so the tool is separable from the dedicated tools without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear when-to-use rule (only endpoints the dedicated tools don't cover) and points to bridge_docs_search as the alternative for discovering paths, plus a precondition to confirm with the user before mutations. It stops short of enumerating which sibling tool covers which operations, so the agent must infer that preference ordering.

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=false, destructiveHint=false and openWorldHint=true, and the description contributes genuinely useful behavior beyond them: the link expires in 30 minutes and Coexistence is supported. It omits whether links are single-use, whether repeated calls create multiple concurrent links, and any rate-limit or auth constraints — reasonable gaps for a low-complexity tool but not a complete behavioral picture.

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, both load-bearing: the first defines the artifact and its constraints, the second tells the agent what to do with the result. The expiry and the key next step are front-loaded 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 compensates by telling the agent that a connect_url is returned and should be shared — exactly the information an agent needs after the call. For a two-optional-parameter creation tool this is nearly complete; only edge behavior on expired or repeated links is unstated.

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 (state and display_name) are already fully documented in the schema, and the description adds nothing about them. It does mention connect_url, but that is an output rather than an 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?

Names a specific verb (create) and resource (a short-lived Connect link), plus the concrete flow it serves (Meta Embedded Signup, Coexistence supported) and the 30-minute lifetime. None of the sibling tools (send_text, list_numbers, send_template) do anything similar, so it is unambiguously distinguishable.

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 intended use case is clear — obtain a link for a business to connect its WhatsApp number and hand that link to the owner, which is stated explicitly as a next step. It stops short of naming when NOT to use it (e.g. reusing an existing link, whether an unexpired link can be refreshed) or pointing at any alternative tool for other onboarding paths.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds two pieces of context beyond them: the auth requirement ("No partner key needed") and the response shape ("matching sections with a preview"), the latter usefully signalling truncated results. It does not mention result limits or ranking, keeping it at 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?

Four short sentences, zero filler: what is searched, what comes back, when to use it, and what auth is required. The most decision-relevant facts (scope and return shape) 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?

For a single-parameter read-only lookup with no output schema, the definition covers purpose, coarse return shape, and auth requirements. The only residue is that it doesn't state whether results are limited or how to move from a preview to full content via bridge_docs_section.

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 single "query" parameter is documented in the schema with concrete examples ("webhook signature", "error 131047"). The description adds no syntax, scoping, or format guidance beyond that, so this is baseline territory where 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 names a specific verb ("Search") and a clearly scoped resource: the WasapFlow Bridge API reference, partner guide and changelog. It also states the return shape ("matching sections with a preview"), which separates it from the sibling bridge_docs_section that presumably fetches a full section. It stops short of naming that sibling explicitly, so it is clear but not fully differentiated.

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 before writing integration code" gives a concrete usage context that an agent can act on. There are no explicit exclusions or named alternatives (e.g., when to follow up with bridge_docs_section instead of searching again), so it sits just below 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 declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds two useful behavioral facts beyond that: sub-sections are included in the result, and no partner key is required. It is silent on ambiguous or unmatched headings (error vs. best match), which is the main remaining behavioral unknown.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single well-formed sentence with the core action front-loaded, followed by examples and an auth note that earn their place. The example list is slightly long but directly supports the required heading parameter.

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 read-only docs lookup with full schema coverage and no output schema, the description is nearly complete. The only meaningful omission is what happens when the heading does not match or matches multiple sections.

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, including the doc enum. The description adds value by grounding the 'heading' parameter with four concrete real-world examples, but adds nothing about matching behavior beyond what the schema states.

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 and resource ('Return the full text of one section ... of the WasapFlow Bridge docs') and clarifies the scope includes sub-sections. It does not explicitly differentiate itself from the sibling bridge_docs_search, so it falls short of 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?

Usage is only implied: the phrase 'full text of one section' hints this is the read-by-heading counterpart to bridge_docs_search, but no sibling is named and there is no explicit when-not guidance. The four example headings help an agent recognize the intended input shape, which is the main practical guidance provided.

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 read-only and open-world annotations, it discloses the failed-delivery-only scope and that delivery errors accompany the events. It leaves ordering, history or retention, and result truncation behavior 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?

Two short sentences front-load the resource and scope, then provide the diagnostic use case. The parenthetical about included errors is compact, and no wording 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?

For a simple read tool with one optional parameter, this is enough to investigate missing inbound messages and expect failed events with errors. It would be more complete with a brief distinction from bridge_retry_webhooks and basic result-window behavior, especially because there is no 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 description coverage is 0%, and the description does not explain the sole limit parameter. The schema supplies its default and numeric bounds, but the definition does not explicitly describe its effect on the returned events or how to handle truncated results.

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 identifies the exact resource—webhook events Bridge failed to deliver to the user's URL—and states that the error is included. It clearly implies a diagnostic listing, though it does not explicitly contrast this read tool with bridge_retry_webhooks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence provides a concrete trigger: use the tool when incoming messages are missing in the CRM. It does not explain when to use bridge_retry_webhooks or other diagnostic siblings instead, so the selection guidance is useful but not exhaustive.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered and the description is consistent with it (a planning/guidance tool, not a mutation). The description adds genuinely useful context beyond annotations: what the plan contains and that 'No partner key needed,' which removes a common auth blocker before the agent even attempts the call.

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 deliverable and then the concrete steps, which lets an agent decide quickly whether this matches the request. The step enumeration is dense but earns its place as a preview of the output; the only waste is the slightly redundant restatement of intent in the second clause.

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, no-output-schema tool, the description is complete enough: it says what is returned (a step-by-step plan), what the plan covers, and when to call it. The only minor gap is not clarifying whether the plan is static guidance or personalized to the caller's existing account state.

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. The description correctly implies no inputs are required to obtain the plan.

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 (the official WhatsApp Business API integration via WasapFlow Bridge) and a specific output form (a step-by-step plan), and enumerates the plan's contents: account, card, keys, webhook, Connect WhatsApp button, first message. An agent can distinguish this onboarding-plan tool from siblings like bridge_docs_search or bridge_docs_section 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 routing guidance: 'Call this first when someone wants to build or connect WhatsApp.' That establishes both the trigger condition and call ordering. It does not name an alternative sibling for adjacent needs (e.g., searching docs for a specific existing integration problem), so it stops short of full when/when-not coverage.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful scope context (only numbers registered to this partner) and notes status is included in the result, but says nothing about result volume, truncation, or how the limit/pagination behaves, which matters for a list tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with the resource front-loaded and no filler. The trailing "with status" is slightly ambiguous about what status values are returned, but no wording is wasted.

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?

This is a low-complexity read tool with no output schema, so the description needn't explain return values in depth. However, with no output schema and an undocumented limit parameter, an agent still lacks guidance on result size and paging, which is a meaningful gap for a listing operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter (limit, default 50, max 200) has 0% schema description coverage and is never mentioned in the description. The description therefore adds no meaning about what limit controls or what happens when more numbers exist than the limit, leaving the one parameter undocumented in both places.

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 ("List the WhatsApp Business Accounts (client numbers)") and clarifies the scope as those "registered to this partner." It does not explicitly distinguish itself from the sibling bridge_number_status, which the phrase "with status" partially overlaps with, so it stops short of 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?

There is no statement of when to use this tool versus alternatives such as bridge_number_status or bridge_usage. The listing intent is only implied by the verb "List"; no prerequisites, exclusions, or routing guidance 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the useful behavioral hint that results carry approval status, but says nothing about pagination, result volume, or rate limits for a call that could return many templates.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with the resource front-loaded and zero filler. It is terse to the point of terseness being the only risk, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool with a fully described schema and read-only annotations, most of the burden is already carried elsewhere. However, with no output schema, the description could say more about what a returned template record contains (id, name, language, category) beyond the single mention of approval status.

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 waba_id parameter is already fully documented, including a pointer to bridge_list_numbers. The description adds no format or sourcing detail beyond the schema and slightly blurs things by calling the scope "a number."

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 ("List the message templates") and adds the key returned attribute (approval status), which tells an agent this is a status-inspection call rather than a send. It does not distinguish itself from siblings such as bridge_send_template, and it says "of a number" even though the required parameter is a WABA ID, leaving a small terminology mismatch.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance, no prerequisite or ordering advice (e.g., call this before bridge_send_template to check approval), and no named alternative. The intended usage is only loosely inferable from the verb "List".

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: no indication of whether results are paginated, how they are ordered, whether all statuses are returned when the filter is omitted, or roughly 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?

It is a single short sentence with no filler, which is appropriate in length. However, the clause 'and replies status' is grammatically muddled and front-loading the filter behavior would have been more useful than the ambiguous addendum.

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 a zero-coverage parameter schema, the description needs to explain default behavior, filtering semantics, and result shape for an open-world listing tool. It covers none of these, leaving an agent unable to predict what a call with no arguments returns.

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 0%, so the description carries the burden of explaining the single 'status' parameter — yet it never states that the parameter filters results, nor what happens by default (all tickets?) when it is omitted. The enum values live only in the schema, and the description does not connect them to filtering behavior.

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 verb and resource ('List support tickets'), which is better than a bare restatement of the name. But the trailing 'and replies status' muddies the purpose — it is unclear whether this lists tickets, ticket replies, status metadata, or all three, and nothing distinguishes it from siblings such as bridge_open_ticket or bridge_failed_webhooks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this versus the other bridge_* listing tools, and no stated preconditions (auth, connected account, openWorld requirements). The agent is left to infer usage entirely from the tool name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered by structured data. The description adds genuine context beyond that: the data is sourced live from Meta and the payload covers quality rating, messaging limit, and name status, which is valuable since there is no output schema. It omits any note on rate limits or behavior for unregistered/invalid numbers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence with the returned fields front-loaded and no filler. It works as a fragment rather than a full sentence, but nothing is wasted.

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, single-parameter tool with annotations covering safety, the description supplies the return-value vocabulary needed in the absence of an output schema. Remaining gaps (error behavior for unknown numbers, freshness/latency of 'live' data) are minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the sole parameter waba_id is documented in the schema, including a pointer to bridge_list_numbers. The description contributes nothing about waba_id (scoping, format, partner-account requirement), so it sits at the baseline for a fully documented single 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?

The description names the resource precisely (live status of a WhatsApp number from Meta) and enumerates what the status comprises: verified name, quality rating, messaging limit, and name status. That is enough to distinguish it from bridge_list_numbers, though the sibling relationship is only implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the phrase 'Live status of a number', so an agent can infer this is the per-number inspection call versus the listing call. However, it never says when to prefer this over bridge_list_numbers or what preconditions (partner registration, number onboarding) must hold.

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 this as a non-read-only, open-world, non-destructive write, so the agent knows the safety profile. The description adds useful evidence-gathering requirements (timestamps with timezone, Meta error code, fbtrace_id, attempts made, business impact), but says nothing about what the call returns, whether tickets can be duplicated, or any rate or size constraints beyond the 20 KB item in 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 sentences with zero waste: the purpose is front-loaded and the evidence checklist follows immediately. The parenthetical '(with timezone)' and the named Meta identifiers make the guidance concrete 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?

For a six-parameter, open-world creation tool with a nested diagnostics object and no output schema, the description covers the message content well but omits what a successful call produces (e.g., a ticket reference) and how to set priority or category. It is adequate to invoke the tool but not complete enough to steer escalation decisions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 67% schema description coverage, the schema carries most of the load, and the description adds real meaning for the required message field by specifying the evidence it should contain. However, it gives no guidance on choosing category or priority (both enums) or on when to supply waba_id and diagnostics, leaving the discretionary parameters unexplained.

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 and resource ('Open a WasapFlow support ticket'), which an agent can distinguish from the sibling read tool bridge_list_tickets. It is clear about what is created but does not name the sibling or state the boundary between listing and opening tickets explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the agent must infer that this tool is for escalating problems to support rather than handling them with the many operational siblings (bridge_call_api, bridge_retry_webhooks, etc.). There is no explicit when-to-use versus when-not-to-use guidance, and no mention of escalation thresholds or prerequisites.

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

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

Annotations declare a non-read-only, non-destructive, open-world operation, and the description adds the key behavioral fact that omitting event_id retries everything — a materially different blast radius than single-event retry. It does not describe the response, rate limits, or whether retries are queued.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the action, then covers both the single and bulk modes and the prerequisite. 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 one-optional-parameter tool with an output schema absent, the description covers action, modes, and precondition. Only the result of a redelivery (success counts, queued vs immediate) is left unspecified, which is minor here.

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 already labels event_id as optional and sourced from bridge_failed_webhooks, but the schema never says what omission means. The description supplies that meaning explicitly (omit = retry all), which is genuine added semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Redeliver') and resource ('failed webhook event'), and covers both modes: a single event via event_id or all of them when omitted. Referencing bridge_failed_webhooks as the source of the id also distinguishes it from that sibling.

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 usage prerequisite ('after the webhook endpoint is fixed') and the condition that selects bulk mode (omit event_id). It does not explicitly warn against bulk-redelivering when only one event failed, so it stops short of full when/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?

Beyond the annotations, it discloses two important real-world effects: an actual message will be sent and Meta may charge for it. The approval requirement and 24-hour-window behavior add further useful operational context, with no contradiction to the write-oriented, open-world annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences front-load the operation and its key constraint, then cover component formatting and cost. Every sentence contributes useful selection or invocation information without 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?

Together with the fully documented schema and annotations, the description provides enough information to select and invoke this external send safely, including approval, window, format, and billing considerations. Explicit sibling routing for template discovery and ordinary text messages would make it more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the structured fields already document all five parameters. Saying that components follows the Meta Cloud API format adds only modest guidance beyond the schema's existing description of optional header, body, and button parameters.

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 specifies the action and resource—sending an approved template—and the title supplies the WhatsApp context. The 24-hour-window note also distinguishes template messaging from ordinary session text messaging such as bridge_send_text.

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 usage context: the template must be approved, and this method works outside the 24-hour window. It does not explicitly route agents to bridge_send_text for session messages or bridge_list_templates for discovering suitable templates.

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 non-readOnly, openWorld, non-idempotent, non-destructive. The description adds the crucial WhatsApp 24-hour policy constraint and emphasizes 'This sends a real message', reinforcing the non-idempotent, real-world side effect. It omits error behavior and rate limits, 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?

Three short sentences, front-loaded with purpose, then constraint, then alternative, then a caution. No wasted wording.

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 exists, but the description covers purpose, the critical eligibility constraint, and the alternative path. It lacks any mention of failure modes or return shape, a minor gap given annotation coverage.

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%, documenting 'to' format, BSUID, and waba_id. The description adds no further parameter meaning, so baseline 3 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+resource ('Send a text message from a connected number') and explicitly names the sibling it is not (bridge_send_template), so an agent can route without opening 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?

Gives an explicit conditional: free-form text only works within the 24-hour customer service window, otherwise use bridge_send_template. This is exactly the when-to-use / use-alternative guidance that matters for this tool family.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description contributes the return content (plan, numbers, slots, fee), which matters because no output schema exists, but it says nothing about freshness of billing data, the billing cycle, or whether fees are prorated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence that front-loads the resource and lists the payload without filler. Nothing is wasted and nothing needs trimming.

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, enumerating the returned fields is the essential missing piece and the description supplies it. Minor gaps remain around units/currency of the fee and whether usage counters are live, but the core is covered.

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 and the schema is correspondingly empty, so there is no parameter semantics burden to carry. The description correctly implies the call is unconditional with no scoping arguments.

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 resource (the Bridge plan) and enumerates the exact fields returned: active WhatsApp numbers, slots, and the monthly fee. An agent knows precisely what data this yields, though it does not distinguish itself from siblings like bridge_list_numbers, which likely overlaps on the numbers count.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use instruction, no prerequisites, and no mention of alternatives such as bridge_list_numbers or bridge_number_status for number-level detail. The usage is only inferable from the resource name itself.

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