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

With no annotations provided, the description carries the full behavioral burden and uses it well: it discloses that the operation returns immediately, that the server enforces a minimum 30-second delay between sends, and that delivery continues asynchronously in the background. This is valuable transparency for a side-effecting tool, though it does not cover all possible failure or return behaviors.

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

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

Three tight sentences deliver purpose, a key constraint, and the critical asynchronous behavior with no filler. The primary verb and resource are front-loaded, and every sentence adds information an agent needs before calling 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?

For a tool with 8 parameters, all schema-documented, and no annotations or output schema, the description covers the most operationally important facts: bulk scope, count limit, and async delivery behavior. It does not describe return values or what happens on partial failures, but it gives an agent enough context 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?

The input schema already documents all 8 parameters with 100% coverage, so the baseline is 3. The description adds meaningful parameter-related semantics beyond the schema by specifying the maximum recipient count (1000) and the server-enforced minimum delay floor (30 seconds), which directly inform how `numbers` and `delay` should be used.

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 and resource: 'Send the same message to many recipients.' The phrase 'many recipients' immediately distinguishes it from sibling tools like send_message and send_message_fast, which target a single message flow. The max-1000 qualifier further sharpens the scope.

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 makes the intended use case clear: bulk messaging to many recipients, with a hard cap of 1000 numbers per call. It does not explicitly name alternatives like send_message for single-recipient sends, but the context strongly implies when this tool is appropriate. It does not include exclusion conditions, so it stops short of a 5.

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

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

There are no annotations, so the description carries the full burden. It discloses that the tool returns a QR/session state, but it does not explain side effects, whether an existing device must be created first, session validity, or whether reconnecting invalidates an existing session.

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 no filler. The action is front-loaded, and the returned result is stated immediately.

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

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

There is no output schema and no annotations, so the description should explain more about the QR/session state and the device lifecycle. It omits prerequisites like whether the device must already exist and how the returned session state should be consumed, leaving an agent under-informed.

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 device_id is already documented. The description adds no additional meaning beyond 'device to connect', providing the baseline level of value.

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 and resource: 'Start connecting a device' and clarifies the purpose by mentioning the QR/session state used to pair WhatsApp. It is clear, though it does not explicitly distinguish itself from siblings like create_device or renew_device.

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 'used to pair WhatsApp' implies when the tool is useful, but there is no explicit guidance about when to choose this over create_device, renew_device, or list_devices. No exclusions or prerequisites are stated.

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

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

With no annotations, the description carries the burden and it does disclose a key side effect: 'Costs the package price from your balance.' That is valuable beyond the schema. But it does not describe failure modes (e.g., insufficient balance), whether the operation is reversible, or what the response contains; no annotation contradiction exists.

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 action, the cost consequence, and the parameter source. The critical cost warning 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 two-parameter tool with complete schema documentation, the description covers the main prerequisite and the most important side effect. It lacks response/failure expectations and sibling differentiation, but the agent has enough to select and 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 100%, and the schema already documents package_id as 'Package to buy. See list_packages.' The description repeats that source and mentions balance cost, but it does not add new parameter semantics such as format, constraints, or voucher_code behavior 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 states a specific action and resource: 'Create a new WhatsApp device.' It is clearly distinct from messaging and status tools, and the economic consequence (package purchase) adds scope. However, it does not explicitly distinguish itself from sibling connect_device/renew_device, which could also relate to device 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?

It gives a useful prerequisite ('Get package_id from list_packages') and implies the create-via-package workflow, but it does not state when to choose this over connect_device, renew_device, or list_devices, nor any conditions/exclusions such as minimum balance requirements.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns 'live connection status' but gives no detail on the response format, error behavior, or whether it requires any authentication. For a status check, an agent would need to know what 'status' means (e.g., online/offline) and what happens if the device_id is invalid. The description omits these critical behavioral aspects.

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 with no filler. The purpose is front-loaded, and the usage tip adds value. 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 tool with one parameter, no output schema, and no annotations, the description is thin. It fails to explain what the response looks like or how an agent should interpret the status result. Since the output schema is absent, the description should compensate by describing the return value, but it does not. This leaves an agent uncertain about the tool's output, making it incomplete.

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

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

Schema description coverage is 100%, so the schema already fully documents the only parameter (device_id) including its format and optionality when an environment variable is set. The description adds no additional parameter meaning, so the baseline score of 3 applies.

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

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

The description states a specific verb and resource: 'Get the live connection status of a device.' It clearly distinguishes this from broadcast/send tools and even from the enhanced sibling by focusing on 'live connection status.' No tautology; the purpose is immediately obvious.

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 a concrete usage context: 'Check this before a broadcast so you do not send to a disconnected device.' This implies when to use it and why. It does not explicitly name alternatives or when not to use it, but the context is clear enough for an agent to decide.

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

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It states the action is a read ('Get'), implying no side effects, but it does not disclose any potential latency, prerequisites (e.g., device must be online), or output structure. It is not misleading, but it adds minimal behavioral context beyond the action itself.

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 a single, concise sentence that front-loads the core purpose and the key differentiator (message statistics). There is no redundant wording 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?

The tool is simple with one optional parameter and no output schema, but the description does not specify the exact format of the returned statistics or any error conditions. It mentions 'today and total message statistics' but not how they are presented. For an agent to use the result effectively, more detail might be helpful, though the description is adequate for a basic status retrieval.

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 has 100% coverage for the single parameter device_id, including a note about the environment variable fallback. The description adds no additional meaning to the parameter, so the baseline score of 3 applies; the schema already documents it adequately.

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 verb 'Get' and the resource 'detailed device status', and specifies the distinguishing feature: today and total message statistics. This differentiates it from the sibling device_status tool, making the purpose 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?

There is no guidance on when to use this tool versus the basic device_status or other alternatives. It does not mention that basic status queries might use device_status, nor any conditions for choosing this enhanced version. The only implied usage is from the name, but that is not 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?

With no annotations, the description carries the full burden; 'Get' signals a read-only operation and the listed fields indicate what is returned. However, it does not mention authentication needs, caching/live behavior, or the exact response shape, leaving some behavioral context unspecified.

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 with no filler, front-loading the operation and then listing the concrete output fields. It earns its place without 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?

For a zero-parameter tool this is mostly complete: the description tells the agent exactly what account details will be returned. The only small gap is that terms like 'message statistics' are not broken down further, and no error/auth conditions are mentioned.

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, so there are no parameters to document; the baseline for 0 parameters is 4. The description adds no parameter semantics, but none are 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 uses a specific verb ('Get') and resource ('account details') and enumerates the returned fields (name, balance/saldo, AI quota, device count, message statistics). This clearly distinguishes the tool from device- and messaging-focused siblings.

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

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

No guidance is given about when to choose this tool over alternatives such as list_devices or device_status, and no exclusions or prerequisites are stated. The intended use is only implied by the tool name and the listed fields.

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

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

With no annotations, the description must carry behavioral disclosure. It implies a read-only operation via 'list' and adds account scope and status inclusion, but it does not explicitly state that no data is modified, nor does it mention authentication or rate limits. The implicit read-only nature earns a middle score.

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 a single, front-loaded sentence with no filler. It communicates the core purpose efficiently and directly.

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 paginated list tool, the description is adequate but minimal. It states the output includes connection status, and the schema covers pagination. However, with no output schema and no mention of response format or edge cases (e.g., no devices), an agent might lack some context. The presence of closely related sibling tools makes the lack of differentiation a gap, though that falls under usage guidelines.

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% since both parameters (page and limit) have descriptions. The tool description does not add any meaning beyond the schema, so a baseline of 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?

The description states a specific verb ('List'), a clear resource ('every WhatsApp device'), and the scope ('on this account') while also specifying what information is returned ('connection status'). It distinguishes itself from device_status tools by explicitly covering all devices, not a single one.

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

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

The description gives no guidance on when to use this tool versus alternatives like device_status, device_status_enhanced, or list_packages. It only states what it does, leaving the agent to infer when to pick it.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only action by 'List', but does not detail side effects, error behavior, authentication requirements, or whether the result depends on a device context. This is minimal for a tool with no annotation safety net.

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, front-loaded sentence with zero waste. The core action and resource are stated immediately, making it efficient and easy to parse.

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 no-parameter list tool, the description is adequate but leaves a gap: it mentions 'for a device' yet provides no parameter to specify which device, implying a global list or an unclear context. It does not describe the return format or any filtering options, but given the simplicity and lack of output schema, it remains minimally 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?

The schema has zero parameters, so the baseline is 4. The description adds value by stating that results include prices, which is not captured in the empty schema. It clarifies expected output content, aligning with the baseline for no-param tools.

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 'List' and a resource 'packages you can buy for a device' with a key attribute 'with prices'. It distinguishes itself from siblings like list_devices by focusing on purchasable packages rather than device inventory.

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 no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It merely states what it does without contextual cues about typical use cases or situations where it would be inappropriate.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the basic action. It omits important behavioral traits such as whether this causes a financial charge, extends the subscription from the current expiry date, or returns confirmation data. The phrase 'buying a package' hints at a purchase, but significant ambiguity remains.

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 a single, direct sentence with no filler or redundant repetition. It communicates the core action efficiently and is appropriately 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?

This is a three-parameter mutation tool with no annotations and no output schema, yet the description only covers the basic purpose. Missing context includes prerequisites (active device, existing subscription), the meaning of a renewal package, potential side effects such as billing, and what response to expect.

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 parameters are already documented in the input schema. The description adds no additional meaning beyond what the schema provides, and does not clarify how voucher_code interacts with the renewal 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?

The description uses a specific verb ('renew') and resource ('device subscription'), and clarifies the mechanism ('by buying a package'). It clearly differentiates this tool from siblings like create_device or device_status, since renewal is a distinct lifecycle operation.

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?

No guidance is given for when to use this tool versus alternatives. It does not mention that create_device is for new devices, that list_packages should be consulted before selecting a package, or any conditions under which renewal is applicable.

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

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

With no annotations provided, the description carries the full behavioral burden. It usefully discloses a key trait: existing numbers are skipped, not overwritten. However, it does not mention what happens on success or failure, whether any device context is required, or what the return/result behavior is beyond the skip rule.

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 short sentences with no filler. The primary action is front-loaded, and the important deduplication behavior is stated immediately afterward.

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 tool with only two required parameters, full schema coverage, and no output schema, the description is nearly sufficient. The main missing element is return/response behavior, but the deduplication rule and schema-provided parameter details give an agent enough to call 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 description coverage is 100%, so the schema already documents nama, nomor, and device_id fully. The description adds context about duplicate handling for existing numbers, which relates to nomor, but it does not provide additional parameter-level meaning beyond the schema.

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

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

The description states a specific verb and resource: 'Save one contact.' It also distinguishes itself from the sibling tool save_contacts_bulk by explicitly limiting itself to a single contact, making the tool's scope immediately clear.

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 'Save one contact' implies this is for single-contact use, especially given the save_contacts_bulk sibling, but it does not explicitly say when to choose this tool over alternatives or when not to use it. Usage context is present but not fully articulated.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose two useful traits: the 1000-contact cap and that existing numbers are skipped rather than overwritten. However, it says nothing about return values, partial failures, validation, or whether one bad contact aborts the whole batch.

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 tight sentences with no filler. The primary function and batch limit are front-loaded, and the dedupe behavior follows immediately. Every sentence earns its place and can be scanned in one pass.

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 tool with 100% schema coverage, the core contract is present: batch contacts, a size limit, and dedupe behavior. However, with no output schema and no annotations, the agent is left without any indication of what the API returns on success or partial failure, so the context is incomplete.

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 fully describes both parameters, so the baseline is 3. The description adds extra semantic value by stating 'existing numbers are skipped,' which effectively identifies 'nomor' as the deduplication key beyond the schema's plain 'Phone number' 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 opens with a specific action and resource: 'Import up to 1000 contacts in one call.' It clearly presents a batch operation with a hard capacity limit, which allows an agent to distinguish it from the singular sibling tool 'save_contact' 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?

The 1000-contact batch phrasing implies this is for bulk imports rather than single-contact saves, but the description never explicitly says to use 'save_contact' for one contact or states when this tool should be preferred. 'Existing numbers are skipped' adds context but no explicit 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'through a QR-scan device,' implying device connectivity requirements, but it does not disclose rate limits, delivery semantics, potential errors, or whether the call blocks or is asynchronous. For a mutating send operation, this is a significant gap.

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

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

Two sentences with zero filler. The core action and primary use case are front-loaded. The second sentence adds the 'normal way' positioning. It is efficient and readable, though slightly thin on detail.

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 does not explain the response format (e.g., whether it returns a message ID or delivery status), error conditions, or limitations beyond the media size cap. It also omits guidance on how to construct a quoted message or handle missing device IDs. For a send tool with no annotations, this is incomplete.

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 all five parameters are fully documented in the schema. The description adds no additional meaning beyond what the schema already provides—it doesn't clarify the mutual exclusivity of message and media_url, nor does it explain JID or device_id nuances beyond the schema. 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?

The description states a clear verb-resource pair: 'Send a WhatsApp text or media message to one recipient.' It also positions itself as 'the normal way to reply to a customer,' which differentiates it from siblings like broadcast_message (multi-recipient) and send_message_fast (a faster variant). This makes it easy for an agent to select.

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

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

The description says 'This is the normal way to reply to a customer,' providing some usage context. However, it does not explicitly contrast with send_message_fast or broadcast_message, nor does it mention any exclusions or prerequisites (e.g., that the device must be connected). Usage guidance is implicit rather than 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?

No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait (skipping the typing indicator) but omits other relevant details like authentication requirements, side effects, or response format. Since it is a send operation, the mutation nature is implied but not stated. The description adds some behavioral context but is not comprehensive for a write operation.

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 with no wasted words. The key differentiator (skipping the typing indicator) is front-loaded, and the usage condition follows immediately. This is a model of conciseness.

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 gives the essential differentiator and usage condition, but given the absence of annotations and an output schema, it leaves out return value details and potential error conditions. It also does not mention the optional device_id requirement unless the environment variable is set, though the schema covers that. For a variant tool, it is adequate but not fully 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?

The description does not add any parameter-specific meaning. However, schema coverage is 100% (all four parameters have descriptions), so the schema already explains the parameters. The description's reference to 'Same as send_message' implies the same parameters, but it does not elaborate. Baseline 3 is appropriate because the schema handles parameter documentation.

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 says 'Same as send_message but skips the typing indicator,' which implies it sends a message and clearly distinguishes it from the sibling. It does not explicitly state the verb and resource ('send a message') but relies on the sibling for context, which is acceptable given the close relationship. The purpose is clear for an agent that knows send_message.

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 states when to use: 'Use for time-sensitive messages such as OTP.' It also names the alternative 'send_message' implicitly through 'Same as send_message,' so the agent knows the default option. This is clear guidance without ambiguity.

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

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

No annotations are provided, so the description carries the full disclosure burden. It reveals cost per delivery, setup requirements, defaults for app_name, template approval constraints, and custom_message length/placeholder rules. It does not mention rate limits or error handling, but for a simple OTP send operation this is adequate.

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 packed with information but every clause earns its place. The primary action is front-loaded, and the method breakdown follows logically. No fluff or redundant restatement of the schema.

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

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

For a tool with 7 parameters and no output schema, this description covers method selection, costs, prerequisites, defaults, and constraints. An agent can confidently call it without additional lookup. The only omission is return-value behavior, but that is not required in the absence of an output schema.

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

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

Schema coverage is 100%, yet the description adds substantial value beyond the schema: it assigns cost to each method, clarifies that waba_user requires an APPROVED template, specifies the custom_message placeholder requirement, and states default values. This is exactly the kind of enrichment that helps an agent pick correct 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?

States a specific verb and resource ('Send a one-time password') and immediately enumerates three delivery methods with distinct costs and prerequisites. This clearly distinguishes it from sibling tools like send_message and send_waba_template, which are general messaging 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?

Explicitly instructs the agent to 'Pick the method deliberately' and explains the trade-offs: WhatsApp via Kirimi costs Rp 595, device is free, and waba_user uses an approved template. It also lists required companion parameters for each method, leaving no ambiguity about when to choose which.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It does reveal important platform constraints: templates cannot be replaced with free text, WABA cannot send to groups, and the addressing uses waba_id rather than device_id. Yet it omits prerequisites like template sync, delivery semantics, error behavior, or permission requirements, leaving notable gaps for a mutation-style 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?

Three sentences with no filler: the first states the core action, the second mandates template usage, and the third sets hard limits. Every sentence adds distinct value and the purpose is 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?

The description covers the most critical WABA-specific constraints and the schema fully documents all parameters. However, with no output schema and no annotations, it lacks mention of response/acknowledgment behavior, template sync prerequisites (e.g., using waba_sync_templates first), or error cases, so it is complete enough for basic selection but not for full confident execution.

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 baseline is 3. The description reinforces waba_id being distinct from device_id, but the schema already states this. It adds no additional meaning for to, header, variables, or template_name beyond what the input schema provides.

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 and resource ('Send an approved WhatsApp template through the official WhatsApp Business API') and immediately differentiates this tool from siblings by emphasizing WABA-specific addressing and the free-text prohibition. An agent can distinguish it from send_message, broadcast_message, and waba_reply without inspecting 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 clearly establishes a key usage context: business-initiated conversations MUST use a template and cannot substitute free text. It also excludes group sends. However, it does not explicitly name alternative tools or state when to use send_message instead, so it lacks the full explicit when/when-not alternative guidance for a 5.

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

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

With no annotations, the description carries the burden of disclosing behavior. It only states the return value and says nothing about whether verification consumes/invalidates the code, whether it is idempotent, or what happens on failure. This is a meaningful gap for an OTP check.

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 no filler; the primary action is front-loaded and the return behavior is stated immediately. 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 simple two-parameter tool with no output schema, the description states the essential purpose and return value. However, it omits side-effect and error behavior, which matters because an OTP verification may alter the code's state and the tool has no annotations to cover that.

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 both parameters are already documented with format and meaning (phone without '+', 6-digit code). The description adds no parameter-specific detail, so it meets the baseline but does not exceed the schema.

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

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

The description names a specific action ('Check an OTP code') and a concrete resource (the code the customer received), and clarifies the outcome ('Returns whether the code is valid'). It is clearly distinct from send_otp and send_message siblings, though it does not explicitly name an alternative.

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 'the customer received' implies this tool is for verifying an OTP after it has been delivered, but there is no explicit guidance on when to prefer it over send_otp or when not to use it. Its use context is inferable rather than stated.

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

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

With no annotations, the description carries the burden and it provides meaningful behavioral context: the list is filtered to the 24-hour customer service window, and these are the only recipients eligible for free-text replies. It does not describe output format or pagination behavior, but the primary behavioral rule is clearly 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?

Two concise sentences with no filler. The core condition (24-hour customer service window) is front-loaded, and the practical consequence (free-text reply eligibility) follows immediately.

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 paginated list endpoint with no output schema, the description captures the essential selection logic an agent needs to decide to call it. It could mention the response shape, but the schema already covers paging and the tool's purpose is well-defined.

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%: page and limit already have descriptions in the input schema. The tool description adds no extra meaning or constraints beyond the schema, so the baseline score of 3 applies.

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

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

Description uses a specific verb ('List') and a precise resource: customers/conversations still inside the 24-hour customer service window. This clearly distinguishes it from messaging siblings like send_message, send_waba_template, and waba_reply, which perform sending actions rather than listing.

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 communicates when the tool matters: before replying with free text, you need the list of numbers eligible instead of templates. It does not explicitly name alternative tools or state when not to use it, but the context is clear enough for an agent to select this tool appropriately.

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

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

With no annotations, the description carries full burden. It discloses the 24-hour validity constraint and the API rejection behavior, which is critical. It doesn't mention return format or error details, but the core behavioral trait (time window) is clearly stated.

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 with zero waste. The purpose is front-loaded, then the critical constraint is stated immediately, followed by the alternative. 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 simple reply tool with full schema coverage, the description covers the essential usage context (24-hour rule, alternative). It doesn't explain return values, but given no output schema and the tool's simplicity, this is a minor gap. Overall it's sufficient 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?

Schema coverage is 100%, so the description doesn't need to add parameter detail. It doesn't add new semantics beyond the schema; the message object structure is already fully described in the schema. 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?

The description clearly states the tool's function: replying with free-form text or media via the official API. It also distinguishes it from template-based sending by explicitly stating the 24-hour restriction, which differentiates it from siblings like send_waba_template.

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: only within 24 hours of the customer's last message, and advises checking waba_list_conversations first. It also states the alternative (send a template) for outside that window, making routing 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?

No annotations are provided, so the description carries the full burden. It usefully discloses a rate limit ('10 syncs per hour') and the external source of the operation ('from Meta'), which are important operational traits. It does not mention authorization requirements or what happens when the rate limit is exceeded, but the critical constraint is covered.

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, purposeful sentences: the first defines the operation, the second gives the usage trigger, and the third warns of the rate limit. No filler or redundant phrasing.

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-required-parameter tool with no output schema, the description provides the key inputs: what to run, when to run it, and the rate limit. It could go slightly further by stating what the response contains, but the core calling context is sufficiently 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?

The schema already documents waba_id with 100% coverage as 'WhatsApp Business Account ID to refresh.' The description reinforces the one-WABA scope but adds no new parameter-level meaning, so the baseline schema coverage score of 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?

The description states a specific verb ('Refresh'), resource ('template approval status'), source ('from Meta'), and scope ('for one WABA'). This clearly distinguishes the tool from siblings like send_waba_template and broadcast_message, which perform different actions.

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 states when to use the tool: 'Run this before sending a newly created template.' This gives the agent a concrete trigger condition and makes the intended workflow obvious, even without naming alternatives.

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