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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, which convey that this is a mutating, non-idempotent operation. The description adds minimal behavioral context ('receive real-time notifications'), which is more about purpose than behavior. It does not disclose success/failure details, webhook delivery mechanics, or any side effects beyond the annotation hints. With annotations covering the basic safety profile, a 3 is appropriate.

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 first sentence fronts the core purpose (register webhook) and scope (specific events), and the second sentence provides a concrete usage scenario. 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?

Given a well-documented schema (100% coverage), clear annotations, and a simple creation operation, the description is sufficiently complete. It covers purpose and usage context. There is no output schema, but that is not required for this tool. It could optionally mention what happens after creation (e.g., whether a webhook ID is returned), but this is not necessary 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 description coverage is 100%: both 'url' (HTTPS URL to receive POST requests) and 'types' (with full enum descriptions for each event type) are well documented in the schema. The description does not add further parameter details beyond that; it only mentions event types incidentally. Baseline 3 is correct when the schema already carries the parameter 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 clearly states the action ('Register a webhook URL') and the resource (webhook) with a specific purpose ('receive real-time notifications for specific JetAPI events'). It lists example event types, which helps distinguish it from sibling webhook management tools like list_webhooks, delete_webhook, and update_webhook. The verb 'Register' unambiguously signals creation.

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 usage context: 'Use it when the user wants their server, CRM or automation (n8n, Make, Zapier) to receive replies or react to WhatsApp/Telegram events.' This clearly identifies when to use the tool. It does not explicitly mention alternatives or exclusions, but for a create operation, the context is sufficient and not misleading.

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 and readOnlyHint=false, and the description adds non-obvious behavior: deletion works only for final 'Delivered' status, happens on all recipient devices, and is limited to tdlib/whatsapp channel messages. There is no contradiction with 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 tight sentences: main action first, then constraints, then a practical usage trigger. There is no filler or redundant restatement 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 destructive operation, the description covers target channels, status prerequisites, cross-device effect, and when to invoke it. The annotations cover safety and idempotency, so nothing needed to call the tool correctly is missing.

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

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

The single parameter delivery_id is fully documented in the input schema, including its origin as delivery.id from send_message. Since schema description coverage is 100%, the description need not restate or expand on the parameter.

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

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

The description clearly states a specific verb and resource: 'Delete a sent message from WhatsApp or Telegram (tdlib)'. It also adds user-facing intent ('unsend or recall a message'), making it easy to distinguish from send_message and delete_webhook.

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 when to use it: 'Use it when the user asks to unsend or recall a message.' It also gives clear exclusions: SMS cannot be deleted, and only messages with final 'Delivered' status are eligible.

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 carry destructiveHint=true and idempotentHint=true. The description adds meaning by disclosing the post-deletion effect ('will stop receiving notifications'), which goes beyond the schema and annotations. It doesn't cover irreversibility, but that is partially implied by destructiveHint.

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

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

Two short sentences with zero redundant wording. The action is front-loaded, and the behavioral consequence is the only extra detail, which 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 one-parameter delete tool with full schema coverage and safety annotations, the description is complete. It explains the effect of the operation, and the sibling set provides enough surrounding context. No return value is expected (no output schema), so nothing is missing.

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

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

Schema description coverage is 100%, with the id parameter already documented as 'Webhook ID to delete.' The description's 'by ID' adds no new semantic detail. A 3 is the baseline for high 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?

The description states a specific verb and resource ('Delete a webhook by ID') and adds a concrete consequence ('will stop receiving notifications'). It is unambiguously distinct from sibling tools like get_webhook, update_webhook, and create_webhook.

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 self-evident: use this tool when you want to remove a webhook by its ID. It doesn't explicitly name exclusions or alternatives, but for a single-purpose delete operation the context is clear enough. A mention of 'use update_webhook to temporarily disable' would have pushed it higher.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds useful context about the account fields and diagnostic uses, but does not disclose further behavioral traits such as error behavior, rate limits, or response structure. With annotations carrying the safety burden, this is adequate but not richer.

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 primary purpose and content are front-loaded, diagnostic use cases are compactly listed, and the sibling alternative is stated in a single final clause. 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 zero-parameter read-only tool with annotations and a sibling for balance, the description is complete. It lists the returned account fields, states when to use the tool, gives diagnostic scenarios, and points to the alternative. No output schema exists, but the description sufficiently communicates the return contents.

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, so the schema imposes no burden and the baseline is 4. The description adds no parameter semantics because none are needed; it appropriately focuses on what the tool returns.

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 ('Get') and resource ('full JetAPI account information'), and enumerates the key fields returned. It clearly distinguishes this tool from get_balance by naming the sibling it is not, making selection 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 explicitly gives usage scenarios: verify the token works, check subscription active, and diagnose undelivered messages due to unauthorized channels. It also provides an explicit alternative ('For just the balance use get_balance'), fully routing the agent to the correct tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds value by revealing the exact data returned (balance, customer ID, channels, sender names) and the practical triggers for calling the tool, which gives the agent beyond-annotation expectations of what the tool exposes.

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, tightly written. The first sentence front-loads the action and result set; the second sentence gives concrete usage scenarios. No filler, no repetition, every clause earns its keep.

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, parameterless, read-only tool, this is complete. It states what is returned, when to use it, and annotations cover safety. Without an output schema, the listed return fields substitute adequately; an agent has everything needed 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?

The input schema has zero parameters, so there is nothing to document beyond the baseline. The description correctly does not invent parameter details and focuses on output, which is appropriate for a parameterless query tool.

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

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

The description names a specific resource (JetAPI account) and a clear verb (Get), then enumerates concrete data items: balance, customer ID, available dispatch routing channels, and sender names. This distinguishes it from siblings like get_account and get_webhook by specifying exactly what is retrieved, so an agent can select it confidently.

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 use cases: 'when the user asks how much money is left, before a large mailing, or to find a valid sender_name for SMS.' This is clear when-to-use context. It stops short of naming alternatives or saying when NOT to use it, so it lacks the full comparison found in 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows it's a read-only operation. The description adds value beyond annotations by specifying that it returns a plain-word explanation of the status and includes details like costs and operator info. This helps set expectations about the response content 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 two sentences, front-loaded with the core purpose and then the usage guidance. Every sentence earns its place: the first defines the operation and what it returns, the second gives explicit context for when to use it. There is no filler or redundancy, making it highly 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?

For a tool with a single parameter and no output schema, the description is quite complete. It enumerates the types of information returned (status, operator info, phone, scheduled time, costs) and notes that the status is explained in plain words. While it doesn't provide a formal structure of the response, that's not strictly necessary given the description's clarity. The usage context is also well specified, covering common scenarios.

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 covers 100% of the parameter, and the parameter 'id' is already described as 'Delivery ID from the send_message or send_file response.' The description does not add any additional semantic detail about the parameter, so it fully relies on the schema. Per the guidelines, baseline 3 is appropriate since schema coverage is high and no extra clarification 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 (Get), a clear resource (delivery status of a specific message by ID), and lists the key details returned (status, operator info, phone, scheduled time, costs). It also mentions the status is explained in plain words, which clarifies its output. This clearly distinguishes it from sibling tools like get_balance or get_account, which are about account-level data.

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 states when to use this tool: 'Use it after send_message or send_file when the user asks whether a message was delivered or read, or why it failed.' It also implies the prerequisite of having a delivery ID from a prior send. While it doesn't explicitly mention alternatives or when not to use it, the given context is sufficient for an agent to select it appropriately among the 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 declare readOnlyHint=true, so safety is covered. The description adds a meaningful behavioral detail: it returns the number normalized to international format, and explains why (e.g., 'when the user wrote it with spaces or brackets'). This goes beyond the schema and annotates the tool's transformation behavior without contradicting the read-only hint.

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, no filler. The core purpose and returned fields are front-loaded, and the normalization detail is added as a clarifying note. Every sentence earns its place; the structure is efficient and scannable.

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 simple single-parameter, read-only lookup tool, and the description fully covers what it does, why it is useful, and what it returns (country, operator, brand, normalized number). No output schema exists, but the description names the return fields explicitly, making it complete for an agent to call 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% (pattern and example provided), so the schema already documents the parameter format. The description adds semantic value by explaining that the tool normalizes input like spaces/brackets to international format, which clarifies expected input and output behavior beyond the schema's pattern.

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 ('Look up') and resource ('phone number information') and explicitly lists the data returned (country, mobile operator name and brand). It also mentions a concrete use case ('before sending to verify the number'), which distinguishes it from sibling tools like send_message or get_delivery_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?

The description provides clear context for when to use the tool ('Useful before sending to verify the number and determine routing'), which implies appropriate timing and purpose. It does not explicitly name alternatives or exclusions, but the context is enough for an agent to infer that it is not for sending or post-send status checks.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so no side-effect warning is needed. The description adds meaningful context by clarifying the data is account-configured and tied to dispatch statistics. No behavior contradicts 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?

Two sentences, front-loaded with the resource and action, with zero filler. The second sentence provides actionable context 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, read-only list operation, the description gives the agent everything needed to call it correctly and understand how the result is used. No output schema exists, but the semantic content is sufficient.

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 and the description correctly avoids inventing parameter details. The only relevant information, that the result is a list of UTM tag labels to be reused as utm_mark, is present.

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 a clear verb and resource: 'Get list of all UTM tags (utm_marks) configured in the JetAPI account'. It also explains the tracking purpose ('for tracking message dispatches'), which distinguishes it from generic list tools among the 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?

It explicitly states when this tool is useful: 'Use it to reuse an existing label as utm_mark in send_message, send_bulk or send_file, so statistics stay grouped.' This is clear usage context, though it does not enumerate when-not-to-use or compare against alternative tag-creation tools (none listed among siblings).

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, making the safe-read behavior explicit. The description adds useful transparency by disclosing what the operation returns (URL and event types), and its scoping to a single ID. No contradictory side effects are suggested.

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 states the action and the output fields without wasted words. Every element earns its place, and the description is immediately scannable.

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 tool, the description is complete: annotations cover safety, the schema covers the parameter, and the description covers the return contents (URL and event types). No output schema exists, but the return information is explicitly provided, leaving no critical 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 schema covers 100% of parameters and already documents id as the Webhook ID with a source hint (from create_webhook or list_webhooks). The description only restates identification by ID without adding syntax, constraints, or relationships beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb+resource: 'Get details of a specific webhook by its ID'. It also enumerates the returned payload ('the URL it posts to and the event types it subscribes to'), making it distinct from sibling tools like list_webhooks (all webhooks) and update/delete/create_webhook (mutations).

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 implies the correct use case: when you already have a webhook ID and need its configuration details. It doesn't explicitly name alternatives or state exclusions, but the 'by its ID' condition gives clear context that distinguishes it from list_webhooks and mutation 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?

The readOnlyHint and openWorldHint annotations already cover the safety profile, so the description does not need to repeat that this is a read operation. It adds that output can be used to see delivery destinations and locate webhook IDs, but it does not describe return format, pagination, or ordering. That is useful but not rich behavioral detail.

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 the core action front-loaded and followed by concrete use cases. Every clause contributes meaning and there is 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?

For a parameterless, read-only list tool, this is complete: it states the scope, explains the two main purposes, and implies the output contains webhook IDs and delivery destinations. With no output schema present, the description still gives an agent everything needed to decide to call it and interpret the result.

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

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

The tool has zero parameters and the schema documents none, so there is nothing to clarify. The phrase 'all registered webhooks' reinforces that there is no filtering, which is a small semantic benefit beyond the empty 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 and resource: 'List all registered webhooks for this JetAPI account.' The word 'all' distinguishes it from the singular get_webhook sibling, and the mention of finding an ID before updating or deleting connects it to the webhook lifecycle siblings without confusing their roles.

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 for when to use the tool: to inspect where events are delivered or to find a webhook ID before updating or deleting. It does not explicitly mention when not to use it or name alternatives such as get_webhook for a single record, but the use cases are specific enough for an 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 mark the operation as non-read-only, non-idempotent, and non-destructive, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: scheduling, UTM marks, dispatch routing cascade, Telegram usernames and tdlib user IDs, and the implication that bulk sends do not return a delivery ID for tracking. Minor caveats such as cost, rate limits, or failure handling are not disclosed, so it stops short of 5.

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

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

The description is compact: a clear first sentence stating the core action, a feature-support list, and then usage guidance with a routing instruction. Every sentence earns its place; no filler or redundant restatement of the title.

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

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

For a tool with eight parameters and no output schema, the description covers purpose, typical usage, and the key limitation around delivery tracking. It is slightly incomplete on what the caller should expect back from a bulk send, but the explicit redirect to send_message when tracking is needed mitigates that gap.

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

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

Schema description coverage is 100%, so the input schema already fully documents all eight parameters, including formats, constraints, and relationships like 'requires "tdlib" in dispatch_routing.' The description only summarizes feature areas rather than adding meaning beyond the schema, making the baseline 3 appropriate.

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

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

The description opens with a specific verb and resource: 'Send the same message to multiple phone numbers at once.' It clearly differentiates from send_message by emphasizing bulk recipients and also names the sibling it should not be used for ('For one recipient... use 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?

It gives explicit use cases ('announcements, campaigns or reminders to a list of recipients') and an explicit exclusion with alternative: 'For one recipient, or when a delivery ID is needed for tracking, use send_message.' This leaves no ambiguity about when to choose this tool over its sibling.

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 meaningful runtime behavior not present in the annotations: multipart/form-data upload, the 10MB native-image threshold, 7-day download-link expiry for larger files, the 100MB maximum, and a concrete supported-format list. It does not describe return values, failure modes, rate limits, or authentication requirements, but the basic mutating nature is already signaled by readOnlyHint=false.

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 moves to usage trigger, file-source constraint, and supported formats/limits; there is little filler. The slight redundancy comes from listing the media types twice in the first two sentences, and the 'via WhatsApp or Telegram' phrasing creates a minor inconsistency with the routing parameter mentioned in 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 19-parameter send tool with no output schema, the input semantics are largely covered by the schema plus this description. However, the description does not state what the call returns, how delivery failures are reported, or which channels actually support file sending versus link fallback. The 'via WhatsApp or Telegram' framing also leaves dispatch_routing values like sms, notify, and max unexplained, so an agent may not fully understand the routing options.

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 schema already documents all 19 parameters. The description adds value by introducing a critical one-of constraint: 'exactly one of: file_path, file_url or file_base64 (with file_name)', plus the size and format whitelist. It does not enrich the routing/scheduling parameters beyond the schema, but the added constraints meaningfully improve parameter selection.

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 action and resource: 'Send a file (document, image, audio, video, contact) to a recipient via WhatsApp or Telegram.' It also enumerates the supported media types, which makes the tool's purpose obvious. However, the stated channel scope is narrower than the schema's dispatch_routing enum, which includes whatsapp, tdlib, telegram, notify, max, and sms, so the purpose is clear but not perfectly aligned with 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 provides an explicit usage trigger: 'Use it when the user wants to share a document, photo, voice message, video or contact card.' It also gives concrete guidance on file sourcing: 'Provide the file as exactly one of: file_path, file_url or file_base64.' It references send_message for recipient rules, but it does not explicitly state when not to use this tool or name send_message for plain-text messages, so it stops just short of full exclusion 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 indicate this is a mutating, non-idempotent operation, and the description adds genuinely useful behavioral context: channel fallback order, scheduling, typing simulation, delivery callbacks, and the resulting delivery ID. It clearly explains recipient selection rules across channels, which goes beyond what the 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?

The description is compact and front-loaded: the first sentence summarizes capabilities, the second gives usage guidance, and the third covers recipient edge cases and return value. Every sentence contributes distinct information without 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?

Despite having 14 parameters and no output schema, the description covers the essential contextual gaps: when to use it, what channels are involved, how recipient identification works, and what the tool returns (delivery ID for get_delivery_status/delete_delivery). The rich per-parameter schema descriptions handle the remaining details, so nothing critical is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds important relational semantics: phone is required except for tdlib (username/tdlib_user_id) and WhatsApp (whatsapp_lid). It also explains dispatch_routing as an ordered cascade and clarifies the meanings of channel names beyond the enum labels.

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') and resource ('text message') with an explicit list of supported channels and a cascade fallback behavior. It explicitly differentiates from siblings by calling out send_bulk for many phone numbers and send_file for media, so an agent can tell them apart immediately.

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 an explicit when-to-use rule: 'Use it when the user asks to text, message, notify or reply to one person or group chat.' It also names the alternatives for other cases ('For many phone numbers use send_bulk; for documents, images, audio or video use send_file'), leaving no ambiguity about routing conditions.

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 establish idempotent, non-read-only, non-destructive behavior. The description adds meaningful context beyond annotations by specifying partial-update semantics and that 'types replaces the whole list', which is critical for correct invocation. No contradiction with 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?

Two sentences with no wasted words. The core purpose is front-loaded, and the most important behavioral caveat about partial updates and list replacement is stated compactly.

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 3-parameter tool with fully documented schema and adequate annotations, the description covers what the tool does, what it changes, and how the update behaves. No output schema exists, so not describing the return value is acceptable.

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 clarifying that omitted parameters are preserved ('Pass only what should change') and by reinforcing that the types parameter is a full replacement, which is useful behavioral guidance beyond field names.

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 clear verb and resource: 'Update an existing webhook', then names the exact mutable parts (URL and event types). This distinguishes it from siblings like create_webhook, list_webhooks, and delete_webhook without needing schema inspection.

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 targets an existing webhook needing changes, and 'Pass only what should change' conveys partial-update usage. It does not explicitly name alternatives or when-not-to-use, but the 'existing webhook' framing plus sibling tool names makes the intended context unambiguous.

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