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

Annotations already declare destructiveHint=true and readOnlyHint=false, so irreversibility is covered. The description adds the actual HTTP route, which is useful, but says nothing about whether deletion is permanent, idempotent, or fails silently on an unknown media_id.

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 lines, action stated first, endpoint second. Nothing is padded, though the raw endpoint line is developer-facing and only partially earns its place for an agent.

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 presence of an output schema removes the need to describe return values, and the annotations cover the safety profile. Still missing is the practical context of obtaining the media_id and the permanence of deletion, which matters for a destructive one-arg tool.

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

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

Schema description coverage is 0% for the single parameter, and the description only indirectly hints at its meaning by embedding '{media_id}' in the endpoint template. It never states the identifier's origin or format, so it adds marginal meaning over the bare schema.

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

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

States a specific verb and resource ('Delete previously uploaded WhatsApp media') plus the backing endpoint, so the action is unambiguous. It distinguishes itself from the sibling upload_whatsapp_media by implication only; it never names the counterpart operation or other 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 when-to-use guidance, no when-not-to-use, and no mention of where a media_id comes from (presumably the upload_whatsapp_media response). The agent is left to infer the full lifecycle from sibling names.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the upstream endpoint mapping and the supported message_type constraint, but says nothing about batch size limits, partial-failure behavior, or rate limits for a bulk query.

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

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

Front-loaded with the purpose, followed by endpoint mapping and the critical item format in two short sentences with no filler. The endpoint line is slightly extraneous but serves as a lead-in to the payload shape.

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?

An output schema exists, so return values need not be described. Combined with readOnlyHint, the description covers the essentials an agent needs (batch scope, item schema, SMS-only constraint); only batch-size and error-semantics details are absent.

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 0% and the single `items` parameter is an untyped object array, so the description carries the burden — and it does: it gives the exact item shape `{"id": <message id>, "message_type": "SMS"}` and notes SMS is the only supported type. It does not state whether the array size is bounded, but the core structure is fully supplied.

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 ('Query the status of multiple messages at once') and the batching scope distinguishes it from the single-message sibling get_message_status. It stops short of naming that sibling explicitly, so the differentiation is implied rather than stated.

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

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

The phrase 'multiple messages at once' implies the batch use case versus the single-message alternative, but no explicit when-to-use, when-not-to-use, or named alternative (get_message_status / send_batch) is given. Usage is inferable but not guided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds the concrete REST endpoint, which helps the agent understand the underlying call, but says nothing about error behavior for unknown message ids or throttling. A 3 is appropriate given annotations carry the safety profile.

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 lines, the purpose is front-loaded and the endpoint mapping follows as supporting detail. No filler and nothing redundant.

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

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

The tool is a simple single-item read, annotations cover the safety profile, and an output schema exists so return values need not be described. The description supplies the endpoint and parameter placement, leaving only minor gaps around failure cases.

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

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

Schema description coverage is 0%, so the description must compensate. It partly does: placing {channel} and {message_id} in the URL path clarifies that both are path segments, which the bare schema does not convey. It still gives no format hint for message_id or note that the channel enum values come from the path vocabulary.

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 ('Query the status of a single previously-sent message'), and the word 'single' implicitly separates it from the sibling get_batch_status. However, it never names that sibling, so the differentiation requires the agent to infer it from wording rather than being told.

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 'previously-sent' hints that the message must already exist, but there is no explicit when-to-use, no when-not-to-use, and no routing to alternatives such as get_batch_status for batch lookups. The agent gets no guidance on choosing this tool over its 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses that templates with the same name but different languages appear as separate objects, and flags a genuine auth outlier requiring a portal session cookie with exact header names and env-var equivalents. This is exactly the operational context an agent cannot get from annotations or schema.

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

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

Front-loaded with the purpose, then endpoint mapping, then the auth caveat. Information-dense with little waste; the auth paragraph is longer than ideal but each clause (header names, env-var fallback) is load-bearing.

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

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

No output schema exists, yet the description enumerates the return fields and explains the language-duplication semantics. Combined with the explicit auth instructions, an agent has everything needed to call and interpret this tool correctly.

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

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

The schema has zero parameters, so the baseline is 4. The description lists the fields present on each returned object (name, language, languageName, category, components, status), which adds useful shape information even though there are no inputs to document.

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 (List) and resource (approved WABA message templates) plus the endpoint it maps to. The sibling set is entirely send/media operations, so an agent can immediately distinguish this read-only template-listing tool from the others.

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 implies the usage context (browsing approved templates, presumably before sending), but there is no explicit when-to-use guidance, no prerequisites stated, and no alternatives named. Adequate but leaves the agent to infer the scenario.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false, but the description adds no behavioral context beyond the endpoint path and payload shape. It omits batch limits, partial-failure behavior, ordering, rate limits, auth requirements, and atomicity — all important for a batch send 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?

The description is three short sentences, front-loaded with the core action and followed by the endpoint and payload detail. Every sentence contributes directly to correct invocation, with no filler.

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

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

An output schema exists, so return-value details are appropriately omitted, and the payload shape is referenced. However, for an open-world batch-send operation, the description lacks key operational context such as batch size limits, error handling, and how to track the resulting batch.

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

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

Schema description coverage is 0%, so the schema itself provides almost no semantic detail for the messages array. The description compensates well by explaining that each item follows send_message's payload fields and gives a concrete example with channel, destination, and text, though it does not document every possible field.

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 — 'Send multiple messages in a single batch call' — and clearly distinguishes the batch operation from the singular send_message sibling. An agent can identify the tool's purpose and scope 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 phrase 'multiple messages in a single batch call' implies the intended use case versus send_message, but it does not explicitly state when to choose this tool over send_message, send_broadcast, or get_batch_status. The guidance is implied rather than spelled out.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the write/external-call profile is covered. The description usefully adds the underlying endpoint (POST .../broadcast/sms) and the shape of `endpoints` references, but says nothing about batching, throttling (sleep_duration/batch_size implications), or what happens to partially failed sends.

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, front-loaded sentences with no filler; the action comes first and the constraints follow. The embedded API path is slightly noisy but is the kind of detail that aids mapping to the backend.

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?

An output schema exists, so return values need not be described, and the endpoint structure is covered. However, with six parameters at 0% schema coverage and four of them unexplained — including pacing controls like batch_size and sleep_duration — the definition is not complete enough to invoke the tool confidently.

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

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

Schema description coverage is 0% and only one of six parameters (`endpoints`) is explained, including its {type, id} reference shape. `text`, `batch_size`, `registered`, `sleep_duration` and `max_destinations` are entirely undocumented in both schema and description, so the description does not compensate for the coverage gap.

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

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

States a specific verb and resource ('Send a broadcast SMS order') plus the target types (lists, contacts, groups), so the resource is unambiguous. It does not, however, differentiate itself from siblings like send_message or send_batch, leaving the agent to infer when a broadcast is preferable.

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 one concrete usage constraint — ad-hoc mobile-only destinations require at least 250 entries — which implicitly tells the agent when this tool is and isn't viable. But there is no guidance on choosing between this and send_message/send_batch, and no prerequisites or exclusions are stated.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description goes beyond them usefully: it discloses the REST mapping, that it returns the created message summary, the 250-recipient cap, the mutual-exclusion/override behavior of rich content ('Overrides text/template_name when present'), and that extra is merged verbatim. It omits auth requirements and rate limits, but adds substantive non-obvious behavior.

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

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

Front-loads the core action, endpoint, and return in the first two sentences, then organizes channel-specific payload schemas as bullets. It is long but dense and mostly earns its length; the inline nested JSON examples are wordy given no output/param schema help.

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?

An output schema exists so return values needn't be explained, and the description covers the main content paths. However, for a 19-parameter tool with 0% schema coverage, roughly half the parameters go undocumented, and it defers to an external 'Payload Parameters' section an agent may not have.

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

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

Schema description coverage is 0% for 19 parameters, so the description must carry the burden. It documents the major content-bearing params (text, template_name, rcs, whatsapp, voice, push_notification, extra) and the destination comma-list semantics, but leaves roughly ten params (source, subject, email_cc, email_bcc, reply_to, reply_to_ton, key_values, registered, launch_timestamp, client_message_id) completely unexplained. Partial compensation only.

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 single real-time message via the Soprano Connect API'), names the concrete endpoint (POST /cgpapi/messages/{channel}), and the word 'single' implicitly delineates it from send_batch and send_broadcast 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?

Provides clear context that this sends one message and that either text, template_name, or a channel-specific rich object must be supplied, plus per-channel selection rules (e.g. rcs is RCS-only, push_notification needs a notification object). It stops short of explicitly stating when to choose this over send_batch/send_broadcast, so it is clear but not fully routing.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: the exact endpoint, that it is a multipart upload, and that it uses the connection's normal auth rather than a session cookie. It omits what is created/returned, but an output schema 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?

Compact and front-loaded: the purpose leads, followed by endpoint/path, then the two non-obvious parameter facts and the auth note. No padding, though the parenthetical about session cookies is more detail than most callers need.

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

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

With an output schema present, return values need not be described, and annotations cover the safety profile. The description supplies endpoint, transport, auth behavior and the two ambiguous parameters, leaving only `filename`/`content_type` semantics implicit, which are largely self-evident.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it covers only two of four: `source` (the sender number the media is uploaded against) and `file_content_base64` (raw bytes, base64-encoded). `filename` and `content_type` are left entirely to inference, so the compensation is partial.

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

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

The description gives a specific verb+resource ('Upload media to Facebook for use in WhatsApp messages') and even cites the underlying endpoint, so the agent knows exactly what operation it is. It does not contrast itself against the close sibling delete_whatsapp_media or clarify the upload/send pipeline, so it stops short of 5.

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

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

Usage is only implied: the auth note distinguishes this tool from list_whatsapp_templates, which is a partial when-to-use signal. There is no statement of when to call this versus send_message/send_broadcast, nor prerequisites such as a media ID being needed for later sends.

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