DripRaven WhatsApp campaigns

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

Annotations already declare readOnlyHint and idempotentHint, and the description reinforces that this is a safe identity check. It adds useful semantic nuance beyond annotations: owner_email identifies the human owner, and plan/subscription_status mirror billing_status. This prevents agents from misreading those fields as billing-specific values.

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

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

The description is compact and front-loaded: purpose first, then return shape, then usage triggers, then field clarifications. Every sentence earns its place, and the caveat about plan/subscription_status mirroring billing_status is high-value disambiguation 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 zero-parameter read-only identity tool, the description is complete: it states what the tool does, when to call it, and exactly what fields it returns. There is no output schema, but the inline return object fully compensates. No missing information would prevent an agent from calling or interpreting the result 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?

The tool has zero parameters and the schema coverage is 100%, so the baseline is 4. The description adds no parameter detail (there is none needed), but it does clarify the meaning of the returned fields, which is the only extra semantic value available.

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: 'Identify which DripRaven account/workspace this MCP connection is linked to.' It also lists the exact return payload, making the tool's function unmistakable and distinct from siblings like billing_status and whatsapp_status.

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

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

It gives explicit call triggers: 'when the user asks who/which account or workspace they are connected as, to confirm they are operating on the right account before making changes, or to state the account out loud.' It does not explicitly contrast with billing_status or name when-not-to-use, so it stops short of a full 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?

Annotations provide idempotentHint=true, but the description goes well beyond that by explaining idempotency keyed on phone, the exact fields updated, CRM sync behavior via source/external_id, and the nuanced opted_out semantics including the consent requirement for re-subscribing. This is rich behavioral disclosure beyond what annotations alone convey.

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

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

Three sentences, each earning its place: core upsert behavior, phone format, CRM sync, then opt-out semantics. The most important behavior is front-loaded, and the consent warning is included without expanding into unnecessary prose.

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?

Given seven parameters, nested objects, and no output schema, the description covers the behavioral essentials and parameter semantics well. A small gap is that it does not describe what the tool returns (e.g., contact object vs success indicator) or whether tags/fields are fully replaced or merged, but these do not block correct invocation.

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 71%, and the description adds real meaning to several parameters: E.164 format for phone, CRM sync purpose for source/external_id, and the two-state plus omit behavior for opted_out. It does not add much for name, tags, or fields beyond saying they are updated, but the most nuanced parameters are clarified.

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 ('Add or update a contact') and immediately clarifies the distinguishing behavior: idempotency on phone, updating name/tags/fields when the contact already exists. This separates it from plain create or update tools without needing to inspect 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?

The description gives clear operational context for when to use this tool: it handles both add and update based on phone, and it explains the specific opt-out/re-subscribe decision. It does not explicitly name alternative sibling tools like import_contacts or list_contacts, so it stops short of full when-not-to-use 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 readOnlyHint and idempotentHint annotations, the description discloses the consequence of active being false (sending blocked with SUBSCRIPTION_REQUIRED) and the expected next action. It also explains the structure of plans, giving the agent actionable context not available from annotations.

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

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

The description is front-loaded with the core purpose, then return structure, then usage guidance and error handling. Every sentence carries actionable information with no fluff, making it dense yet efficient.

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?

Given there is no output schema, the description thoroughly explains the return fields, the meaning of 'active', and the follow-up action (get_subscribe_link). It also describes plans so the agent can present pricing options. Nothing critical is missing for correct invocation and use.

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 has zero parameters, and schema coverage is 100% (vacuously). The description adds no parameter detail because none exist; per the rubric, baseline for 0 params is 4. It could not add more meaning here.

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 action ('Check whether this workspace can send broadcasts') and explicitly differentiates from siblings by framing it as a precondition for send_broadcast. It also outlines the return fields, making the tool's function unmistakable.

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

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

It explicitly says to call this before send_broadcast when real delivery is expected, and gives the alternative (get_subscribe_link) when active is false. This provides clear when-to-use and when-not-to-use guidance relative to sibling tools.

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 mark readOnlyHint=false and destructiveHint=false, but the description adds substantial behavioral detail: success returns status 'cancelled', failure produces CAMPAIGN_NOT_CANCELLABLE with the current status, and messages already sent cannot be recalled. This goes well beyond what annotations provide and sets correct expectations.

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

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

The description is front-loaded with the purpose, then flows logically through conditions, success/error behavior, and alternatives. Every sentence adds essential information with no filler, making it appropriately sized for the tool's complexity.

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 tool with no output schema, the description covers the success outcome, the failure mode with error code, the prerequisite condition, and the recommended fallback. Nothing an agent needs to decide whether to call it or to interpret the result 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 has only one parameter (campaign_id, uuid) with 0% description coverage. The description compensates by telling the agent exactly where to get the ID ('from send_broadcast or list_campaigns'), adding source context that the schema lacks. Since there is only one param, this fully covers its 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?

The description states a clear verb ('Cancel') and specific resource ('a scheduled broadcast so it never sends'). It also distinguishes from siblings by noting the alternative for in-flight/completed sends (disconnect_whatsapp), so an agent can immediately tell this tool apart without opening other 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?

Explicitly defines the valid usage window ('only works while the campaign is still scheduled') and states when it cannot be used (started/finished). It names the exact alternative for those cases (disconnect_whatsapp), leaving no ambiguity about selection criteria.

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 provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false. Description adds critical behavioral context: token validation, success sending broadcasts, failure with VALIDATION_ERROR, and the limitation that delivery/read stats won't update (due to webhook wiring). This goes beyond annotations, explaining side effects and constraints.

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?

Description is a single paragraph but front-loaded with the core action and alternative context. Each sentence adds value: the flow, validation, return, failure mode, and caveat. Slightly verbose but justified given the complexity of the tool.

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?

All necessary information for an agent to call correctly is present: required parameters, how to gather them, expected return shape, error behavior, and a key limitation (stats won't update). No output schema but description clearly states the return values. Comprehensive for a connection tool with 3 params.

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 covers 100% of parameters with descriptions, so baseline is 3. Description adds practical guidance on what each parameter is (e.g., 'permanent access_token', 'phone_number_id', 'waba_id') and how the user should obtain them from Meta app setup. This enriches schema descriptions by connecting them to the usage flow.

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?

Clearly states it connects a workspace's WhatsApp by using user-provided credentials, explicitly framing it as the 'bring your own credentials' alternative to the browser signup popup. Distinguishes from sibling tools like whatsapp_connect_link and disconnect_whatsapp.

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 instructs when to use: 'Use this to connect a workspace's WhatsApp number entirely in chat' and describes the exact workflow of asking the user for three values. Mentions alternative (browser signup popup) and differentiates from disconnect_whatsapp implicitly.

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 indicate this is not read-only. The description adds valuable behavior beyond that: segments are live and always reflect current contacts, and the return shape is specified. This enriches the agent's understanding without contradicting annotations.

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

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

The description is three compact sentences. The primary purpose is front-loaded, followed by a key behavioral trait and the return structure. Every sentence carries essential information 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?

For a tool with a nested filter object and no output schema, the description covers the essential aspects: the resource, the filter composition, the live evaluation behavior, and the return format. It is complete enough for an agent to invoke the tool 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?

Schema coverage is 50% (name lacks a description, filter has one). The description provides a high-level summary of filter types, but the schema already details each filter field (tags, country, custom_field, dates). The description does not elaborate on the 'name' parameter, which is left self-explanatory. It adds marginal value over the schema but does not fully compensate for the coverage gap.

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 ('Create'), a resource ('named reusable segment'), and the exact composition of filters (tags + country + custom field + signup date range). It also clarifies the segment is live and returns a specific structure, distinguishing it clearly from siblings like list_segments.

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 purpose is so clearly defined that an agent can infer when to use this tool (to create a reusable segment). However, it does not explicitly mention alternatives or exclusion conditions (e.g., 'use list_segments to view existing segments'), leaving the decision to inference.

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

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

Goes far beyond the annotations by disclosing crucial behavioral pitfalls: unset variable_mapping sends blank placeholders, body_examples are only for Meta review and never sent, video headers are uploaded and re-sent with every broadcast, and header_text/header_video_url are mutually exclusive. This is exactly the kind of non-obvious behavior an agent needs.

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

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

Long but justifiably so given 10 parameters and Meta-specific approval rules. The most critical warning about variable_mapping is front-loaded, and the video header section is separated. Slight redundancy around body_examples and variable_mapping keeps it from a perfect score.

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?

Despite lacking an output schema, the description states what is returned. It also covers the full lifecycle context, approval flow, parameter constraints, and the key distinction between placeholders and examples. An agent has everything needed to call this tool correctly and avoid common failures.

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 already high, but the description adds substantial meaning beyond it: concrete variable_mapping syntax including custom fields like fields.plan_tier, the critical distinction between body_examples and variable_mapping, and the failure mode when mappings are omitted. This materially improves correct invocation.

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 action and resource: 'Create a new WhatsApp message template on the connected WhatsApp Business Account.' It clearly distinguishes from siblings like update_template, delete_template, and list_templates by focusing on creation and the template lifecycle.

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?

Provides strong contextual guidance: new templates start PENDING review, only APPROVED templates can be broadcast, and users should poll sync_templates/list_templates. It does not explicitly name an alternative tool for modifying existing templates, but the context makes the intended use unambiguous.

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 destructiveHint=true, so the description adds value beyond that by stating the deletion is permanent, covers all languages, and returns nothing. This gives the agent a concrete understanding of the impact and result, which is not fully captured by the annotations alone.

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 compact sentences with no filler. The critical consequences (permanence, all languages, confirmation) are front-loaded, and the return behavior is clearly stated. Every word earns its place.

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 destructive tool with one parameter, the description covers all necessary context: the effect on both systems, the irreversibility, the confirmation requirement, and the absence of a return value. With no output schema, this is fully sufficient for an agent 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?

Schema description covers 100% of the single parameter (template_id) with a clear reference to list_templates. The description does not add further parameter-specific meaning, so it stays at the baseline of 3 for full schema coverage.

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?

Clearly states the action (permanently delete), the resource (message template), and the scope (from WhatsApp Business Account and DripRaven). It also distinguishes from siblings like update_template or sync_templates by focusing solely on deletion. The mention of removing all languages adds specificity.

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 instructs to confirm with the user before calling due to irreversibility. It does not explicitly mention alternatives, but the purpose is distinct enough (deletion vs. update/create) that the usage context is clear. The confirmation step is a strong, actionable guideline.

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 description adds substantial behavioral context beyond the destructiveHint annotation: it states that broadcasts are not delivered until reconnection, that templates/contacts are preserved and re-synced, and it discloses the return value. This fully prepares the agent for the tool's side effects.

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

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

The five sentences each carry distinct, essential information: action, consequence, use case, data retention, reconnection paths, confirmation instruction, and return value. It is front-loaded with the primary action and avoids unnecessary elaboration.

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 tool with no parameters and no output schema, the description fully covers purpose, behavioral consequences, data preservation, reconnection options, and return shape. No critical information is missing for correct invocation.

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 zero parameters, the schema has nothing to explain. The description appropriately omits parameter details and focuses on behavior. The baseline of 4 applies since there are no parameters to add meaning to.

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: 'Disconnect this workspace's WhatsApp number.' It clearly distinguishes from connect_whatsapp and whatsapp_connect_link by stating the opposite action and its effect on broadcast delivery. The purpose is unmistakable.

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 provides explicit use cases ('stop sending from their connected number or re-run signup with a different number') and names the alternatives for reconnection (connect_whatsapp, whatsapp_connect_link). It also includes a safety directive to confirm with the user, making the when-to-use guidance complete.

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 readOnlyHint and idempotentHint annotations, the description adds genuinely useful behavioral context: stats update in real time as Meta webhooks arrive, and recent_errors only appears when sends have failed, capped at 5 distinct reasons. This helps the agent set correct expectations.

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 sentences: the first front-loads purpose and output fields, the second adds behavior and a conditional field. There is no filler or redundant restating of the tool name.

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-only stats tool with no output schema, the description covers the purpose, the returned fields, the live-update behavior, and the conditional error payload. Nothing needed for correct invocation or interpretation is missing.

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

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

Schema description coverage is 0%, so the description carries no explicit parameter guidance. However, the single required campaign_id is self-explanatory and already constrained as a UUID, and the phrase 'for a campaign' connects it to the resource. This is adequate but not enriched beyond the schema.

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

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

The description uses a specific verb-resource pair ('Get live delivery stats for a campaign') and enumerates the exact returned fields, making the tool's purpose immediately obvious. It also reads clearly against sibling tools like list_campaigns or account_status, so there is little room for confusion.

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 clearly frames when the tool is appropriate: retrieving live, per-campaign delivery statistics. It does not explicitly name alternatives or exclusions, but the sibling list and the emphasis on 'live' stats convey the intended context strongly enough.

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?

Even with annotations already marking readOnlyHint=true and idempotentHint=true, the description adds meaningful behavior: it discloses the exact return shape ({ ready, checklist, summary }), the checklist item fields, and the consequence of ignoring readiness ('would fail or, worse, not be delivered'). This goes well beyond annotation basics.

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

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

The description is longer than average but every sentence earns its place: purpose, output schema, checklist schema, when to call, and what to do conditionally. It is front-loaded with the core purpose before diving into usage details, 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?

For a no-parameter, no-output-schema tool, the description is remarkably complete: it explains the result structure, how to interpret checklist items, and the correct agent action when ready is false. An agent has everything required to invoke and act on the tool without external knowledge.

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 has zero parameters and schema description coverage is 100%, so there are no parameter semantics to clarify. Per the baseline for zero-parameter tools, this is a 4 rather than a 5 because the description adds no parameter-specific value, but none is needed.

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: 'Check whether this workspace is set up to send real broadcasts, and what is still missing.' This clearly distinguishes the tool from readiness-adjacent siblings like whatsapp_status or billing_status by focusing on overall broadcast setup readiness.

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

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

It gives an explicit trigger: 'Call this FIRST whenever a user asks to send or schedule a campaign on a new or unfamiliar workspace.' It also names an alternative tool (send_broadcast) and states the condition for not using it ('if ready is false, do NOT attempt send_broadcast'), which is strong when-to-use 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?

Annotations already declare readOnlyHint and openWorldHint. The description adds behavioral context beyond that: the subscription activates automatically after payment, the checkout_url requires no DripRaven login, and the return object varies based on the plan parameter. It doesn't contradict annotations; it enriches them with operation-specific details.

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

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

The description is well-structured, starting with the primary directive 'Prefer this' and then explaining both branches of behavior. Every sentence adds value—use case, return differences, activation, and the sibling comparison. It is concise for the amount of information delivered.

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-optional-parameter tool with no output schema, the description fully explains return formats, the decision logic, post-payment behavior, and how it relates to send_broadcast and billing_status. No critical information is missing for an agent to call this tool 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?

Schema coverage is 100% and the schema already describes the plan parameter well. However, the description adds meaning by explaining how different plan values affect the returned object (subscribe_url vs checkout_url) and the exact semantics of omitting it, which goes beyond the schema's brief description.

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 clearly states the tool obtains a subscription link for the user, and distinguishes it from siblings like billing_status by explaining that this returns a checkout link while billing_status returns plan details. It specifies the exact resource (subscribe_url vs checkout_url) and the conditions for each, making it 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?

The description gives explicit when-to-use guidance: hand the user subscribe_url by default, pass plan only when the user has chosen a tier. It also names an alternative (billing_status) for describing plans in chat, and instructs to retry send_broadcast after subscription activates. This fully covers decision-making for the agent.

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 indicate non-read-only and non-idempotent behavior; the description adds specific behavioral detail: CSV header requirements, custom field mapping, tag application to all imported contacts, and the return summary object. It does not explain duplicate handling or failure modes, but it goes meaningfully beyond the annotation flags.

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

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

The description is compact at three sentences, front-loaded with the action, and contains no filler. Every sentence adds useful information about input format, behavior, or output.

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 tool with three parameters and no output schema, the description covers the main input constraints, a core behavioral effect, and the return object shape. The only notable gap is the unexplained 'source' parameter and lack of explicit error/duplicate semantics, but overall the agent has enough to invoke 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?

Schema coverage is 67% (csv_data and tag), and the description enriches both: csv_data must contain a header row with required 'phone' and 'name' columns, additional columns become custom fields, and tag is applied uniformly. The 'source' parameter remains undocumented both in schema and description, preventing 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?

The description states a specific action (bulk import), resource (contacts from CSV string), and key input format. It naturally distinguishes itself from siblings like list_contacts and add_or_update_contact by emphasizing bulk CSV import and the required columns/custom field behavior.

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 phrase 'Bulk import contacts from a CSV string' clearly establishes the intended use case, and the required-columns detail reinforces when this tool is appropriate. It does not explicitly name alternatives or exclusion cases, but the context is strong enough for an agent to choose it over singular add_or_update_contact.

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 mark this as read-only and idempotent, and the description adds meaningful behavioral detail beyond those: results are ordered most recent first, pagination uses next_cursor, and the response shape is { data, next_cursor, has_more }. This gives the agent a clear model of the tool's behavior without contradicting the annotations.

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

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

The description is compact and front-loaded: it leads with the core action, then covers filtering, pagination, a cross-reference to get_campaign_stats, and the return shape. Every sentence adds necessary operational guidance without redundancy or fluff.

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 paginated list tool with no output schema, the description covers everything an agent needs: ordering, filters, pagination mechanics, how to use the returned ids, and the exact response envelope. Combined with annotations declaring read-only and idempotent behavior, no important context 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 schema already documents all three parameters with 100% coverage, so the baseline is 3. The description adds value by explaining how cursor comes from a previous call's next_cursor and how the overall pagination loop should work. It does not deeply explain the limit parameter, but the schema already states the default and range.

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: 'List broadcast campaigns' with ordering and optional status filtering. It clearly distinguishes itself from get_campaign_stats by telling the agent to use the returned campaign id with that tool. This is unambiguous and differentiated from sibling tools.

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

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

The description provides clear context for when to use the tool by explaining its default ordering, filterable statuses, and pagination protocol. It points to get_campaign_stats for per-campaign statistics, though it does not explicitly state exclusions for other sibling tools. Overall, the usage context is strong and only lacks an explicit 'when not to use' statement.

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 declare readOnly and idempotent behavior. The description adds meaningful behavioral context: ordering, pagination mechanics, and the exact response shape. It does not cover edge cases like empty results or errors, but the core behavior is well disclosed.

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 deliver the resource, ordering, filters, pagination workflow, and response format with no filler. The most important information is front-loaded in the first sentence.

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

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

The description is complete for a read-only paginated list tool: all six optional parameters are documented in the schema, the return shape is explicitly described, and pagination handling is covered. No output schema exists, but the description compensates by naming the response fields.

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 adds value by explaining country as an 'ISO-2 custom field' and clarifying that phone performs an exact E.164 single-contact lookup. It also describes the cursor lifecycle in a way that the schema alone does not fully 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 uses a specific verb ('List') with a clear resource ('contacts') and states the sort order ('most recent first'), making the tool's primary behavior immediately identifiable. This differentiates it from sibling tools that operate on campaigns, segments, or templates.

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 explains optional filters and explicitly positions phone as a single-contact lookup tool ('to look up a single contact'). It also provides concrete pagination guidance ('pass the returned next_cursor to fetch the next page'). It does not name alternatives, but the tool's use case is self-contained and sibling list tools target different resources.

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 idempotentHint=true, so safety is covered. The description adds useful behavioral context: segments evaluate live, so contact_count reflects current contacts. This is beyond what annotations provide, though it doesn't discuss pagination or error cases; but with zero parameters, the description is sufficient.

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

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

The description is concise, around three sentences, with the primary purpose and key behavioral detail front-loaded. Every sentence adds value: what the tool does, when to use it, and the live nature of contact_count.

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?

Given there are no parameters and no output schema, the description fully covers what an agent needs: it explains the return structure, the semantics of contact_count, and how to use the result. No critical information 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 has zero parameters, so there is no schema to describe. The description still explains the output format (array of { id, name, filter, contact_count }), which adds value beyond the empty schema. Since no parameters exist, a baseline of 4 is appropriate because the description clarifies the output and usage.

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 clearly states its purpose: listing all saved segments with their live contact_count. It explicitly distinguishes itself from creation by advising to use it to find an existing segment's id rather than recreating 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?

Provides explicit guidance on when to use this tool: to find an existing segment's id for preview_broadcast or send_broadcast, and implies it should be used instead of creating a duplicate segment. This clearly routes the agent to the appropriate action.

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 indicate readOnlyHint=true and idempotentHint=true, so the description does not need to restate that this is a safe read. It adds useful context about the data being synced from Meta and the approval statuses surfaced, but it does not disclose any additional behavioral traits such as freshness guarantees, pagination, or rate limits. This is adequate but not rich.

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

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

The description is two concise sentences with no filler. The core action and resource are front-loaded, and the second sentence adds directly useful domain context about approval status and broadcast eligibility.

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 list tool, the description fully covers what the tool returns, the source of the data, the key status values, and a practical constraint. There is no output schema, but the description compensates adequately with the key information an agent needs.

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 has zero parameters, so the baseline is 4. The description has no parameter details to add, and none are needed because the input schema is empty. Nothing is missing here.

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 verb 'List', the resource 'WhatsApp message templates', and the source 'synced from Meta', with the approval status field explicitly named. This clearly distinguishes it from sibling write/sync tools like create_template, delete_template, and sync_templates.

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 states a relevant practical context: 'Only APPROVED templates can be broadcast.' However, it does not directly tell an agent when to choose list_templates over alternatives like sync_templates or get_campaign_stats. The usage context is implied but not made explicit.

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 idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it uses real contacts from the segment, returns per-contact rendered previews, and explicitly states the failure signal (unmapped_placeholders or blank/wrong values). It does not contradict annotations. A small gap is that it doesn't mention the limit parameter's effect on preview count, but the schema covers that.

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

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

The description is dense but every sentence earns its place: the core action, the usage context, the return shape, and the error-remediation workflow. It is front-loaded with the most important instruction ('Call this before send_broadcast') and avoids fluff.

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 preview tool with no output schema, the description fully specifies the return value shape, the success/failure signals, and the follow-up action. The sibling list includes send_broadcast and set_template_variables, and the description explicitly ties into both. Nothing an agent needs to invoke 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 description coverage is only 33% (limit has a description; segment_id and template_id only have format: uuid). The description compensates by explaining that segment_id selects the real contacts and template_id is the template to render, and it clarifies the limit's role implicitly through 'per-contact rendered message' and the schema's 'How many sample contacts to render'. It doesn't spell out the parameter names, but the context makes the mapping clear enough.

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 ('Render exactly what a broadcast would send'), a clear resource (broadcast preview using real contacts from the segment), and explicitly distinguishes it from send_broadcast. It also explains the practical purpose (catching personalisation errors like 'Hi Alex' instead of the real name), which makes the tool's role unmistakable.

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 explicitly says to call this BEFORE send_broadcast, tells the agent to show the result to the user for confirmation, and gives a concrete remediation path: if unmapped_placeholders is non-empty or a preview shows a wrong value, fix with set_template_variables and preview again. This is explicit when-to-use guidance with a named alternative and follow-up action.

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?

Discloses validation behavior (requires APPROVED template, rejects unmapped placeholders), the exact error code and its metadata, side effects (sends to every contact), and return values. Goes far beyond the annotations (which only indicate destructive and open-world) by explaining failure modes and fixes.

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?

Long but every sentence adds critical value. Front-loaded with the core action, then covers prerequisites, error handling, and alternatives in a logical order. No redundancy or 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?

Given the complexity (error codes, prerequisites, return values, alternatives), the description is exhaustive. It explains what the tool does, when to use it, how to handle failures, and what it returns, all within a single coherent definition.

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?

Compensates for the 50% schema coverage by explaining the effect of scheduled_at (omit to send now) and timezone_mode (account vs contact). Also implicitly clarifies segment_id and template_id via the resource description and ties template_id to validation 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?

States a specific verb (send or schedule) and a precise resource (broadcast: one approved template to every contact in a segment). Clearly distinguishes from siblings like preview_broadcast and set_template_variables by name and purpose.

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 instructs to call preview_broadcast FIRST, to call get_started for new workspaces, and names alternatives for specific errors (set_template_variables for unmapped placeholders, get_subscribe_link for billing issues). Provides clear when-to-use and when-not-to-use 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?

Adds critical behavioral details beyond annotations: variable_mapping REPLACES the whole mapping, no re-submission to Meta so no re-approval needed, and returns the updated template row. These are not in the annotations and materially affect how an agent invokes it.

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

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

The description is dense but efficient, front-loading the purpose and then layering critical constraints. A few extra clauses (e.g., 'e.g. it said "Hi Alex"...') add clarity without bloat, though it could be slightly more compact.

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 mutation tool with no output schema, it covers the purpose, the replacement semantics, the value formats, the no-reapproval implication, and a suggested follow-up. Nothing essential for correct invocation 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%, but the description adds meaning: for variable_mapping it explains the whole-replacement behavior, requires an entry per placeholder, gives an example, and clarifies value formats (top-level vs fields.<key>). This goes well beyond the schema's generic description.

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 (wire) and resource (template placeholders to contact fields), and provides a concrete scenario (fixing blank/wrong values) that makes its purpose unmistakable. It clearly distinguishes itself from template creation/update by focusing on mapping placeholders, not content.

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 clear context: use this when a broadcast went out with a blank or wrong value, and advises preview_broadcast afterward. It doesn't explicitly name alternatives like update_template, but the use case is strong enough to guide selection.

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 idempotency and non-destructiveness. The description adds useful behavioral context: it runs automatically on connect, pulls an external resource, and returns { synced }. This goes beyond annotations without contradicting them.

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, each earning its place: the operation, the trigger/refresh context, and the return value plus follow-up tool. Information is front-loaded 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 sync tool, the description is complete: it explains what happens, when to call it, what it returns, and what to do next. There is no output schema, but the description covers the minimal return value 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?

There are zero parameters and schema coverage is effectively 100%, so there is nothing for the description to clarify. The baseline of 4 applies because no parameter documentation burden exists.

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 ('Pull'), a clear resource ('latest message templates and their approval status'), and a source/destination ('WhatsApp Business Account' into 'DripRaven'). It also distinguishes itself from list_templates by clarifying that sync populates the data while list_templates is for viewing them.

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

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

It gives explicit when-to-use guidance: call this to refresh after creating a template or getting one approved in WhatsApp Manager, and notes that it runs automatically on connect. It also names the natural follow-up tool, list_templates, making the alternative clear.

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

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

The description discloses important behavioral traits beyond the annotations: the template re-enters review after editing, name and language cannot be changed, and the header_video_url/header_text mutual exclusivity rule. It also notes the daily edit limit for approved templates. The annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false, and the description does not contradict them. It could add more about failure modes or rate limits, but the provided context is strong.

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

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

The description is dense but well-structured, front-loading the core purpose and then layering constraints. It is a single paragraph with clear logical flow: what can be edited, what cannot, special rules, and post-edit behavior. It earns a 4 rather than 5 because it packs many clauses into one long sentence, which could be slightly harder to parse, but it remains efficient and free of fluff.

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?

Given the tool's complexity (8 parameters, 1 required, no output schema), the description covers the critical operational context: editability constraints, review re-entry, header exclusivity, and reference to create_template for placeholder rules. It doesn't explicitly describe the return value beyond 'Returns the updated template row,' which is sufficient. The lack of an output schema is mitigated by that statement. A 4 is appropriate because it is complete for an agent to invoke correctly, though it could mention rate limits or error cases.

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 only 38%, so the description must compensate. It does: it explains the header_video_url/header_text mutual exclusivity, the 'one header only' rule, and the placeholder/example rules referencing create_template. It also clarifies that template_id is the DripRaven template id from list_templates. However, it doesn't detail every parameter (e.g., body_examples, buttons structure), but the schema covers those with descriptions, so the combination 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?

The description opens with a specific verb and resource: 'Edit an existing template's category and/or content (body, header, footer, buttons).' It clearly distinguishes the tool from siblings like create_template and delete_template by focusing on editing existing templates and enumerating the editable fields.

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 provides explicit when-to-use guidance: it states that Meta only allows editing templates that are APPROVED, REJECTED, or PAUSED (not PENDING), and that approved templates are limited to a few edits per day. It also names the sibling create_template for placeholder/example rules, giving the agent clear context for when to use this tool versus 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 include readOnlyHint, openWorldHint, and idempotentHint. The description adds that the tool returns specific fields, that a one-time Facebook login is required and cannot be done by the agent, and that subsequent token exchange/number registration is automatic. This provides actionable behavioral context beyond the hints.

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

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

The description is only three sentences. It front-loads the purpose and return value, then adds the critical user-requirement and the 'connected already true' no-action branch. Every sentence earns its place with no redundancy.

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 parameters and no output schema, the description carries the burden of explaining the return values. It lists the fields and explicitly instructs the agent to surface connect_url and ask the user to finish login, and covers the connected-true branch. It is complete for correct invocation, though it does not elaborate on meanings of 'configured' and 'phone_number', which is a minor gap.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. Per the baseline rule, a 0-parameter tool earns a 4; the description does not need to compensate for any undocumented 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 clearly states a specific verb ('Get the link') and resource ('WhatsApp connect link'), and explains the purpose (so broadcasts reach real phones). It can be distinguished from siblings like connect_whatsapp and whatsapp_status 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 description provides clear context: the link is for the user to complete a Meta-required Facebook login, and if connected is already true no action is needed. However, it does not explicitly name or compare with the sibling connect_whatsapp, so it lacks full alternative routing beyond the connected condition.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the critical behavioral insight that connected=false causes broadcasts to be preview-only and NOT delivered to real phones—context that affects downstream decisions and is not present in the 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 front-loaded sentences with zero waste: purpose and return shape in the first, the key limitation in the second, and routing guidance in the third. Every sentence earns its place.

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 no-parameter, read-only status tool without an output schema, the description provides purpose, return fields, the real-world implication of the result, and explicit guidance to sibling tools. An agent has everything needed to decide whether and when to invoke it.

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

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

The input schema is empty (zero parameters), so schema coverage is trivially 100%. With no parameters, the baseline of 4 applies; the description does not need to explain parameter details that do not exist.

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 combination ('Check whether this workspace has a connected WhatsApp number') and enumerates the returned fields the caller can expect. It also distinguishes itself from send_broadcast and whatsapp_connect_link by making clear it is a read-only status check, not an action.

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 instructs when to call this tool ('before send_broadcast if the user expects real delivery') and provides an alternative path ('if not connected, use whatsapp_connect_link'). The consequence of the false case (preview only, no real delivery) reinforces why the agent needs to check this first.

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