WhatsApp by GREEN-API

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds no behavioral context such as admin requirements, error conditions, or whether the participant must be a known contact.

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 wasted words. It is appropriately concise for a simple mutation 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?

Given the low complexity, rich schema coverage, and annotations, the description is minimally adequate. However, for a group-mutation tool it omits useful context such as required permissions or common failure modes.

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 all three required parameters. The description adds no additional meaning about group_id, instance_id, or participant_chat_id beyond what the 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 states a specific verb and resource: adding a participant to a WhatsApp group. It is clear enough to distinguish from remove_group_participant, but it does not explicitly name or differentiate against sibling tools.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The intended usage is only implied by the tool name and description.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the core purpose, without disclosing return format, rate limits, or whether an instance must be connected.

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 wasted words. It states the tool's purpose immediately and efficiently.

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, read-only check with full schema coverage and rich annotations, the description is largely complete. It does not explain the return value, but that is a minor omission given the tool's simplicity.

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 both instance_id and phone_number documented in the schema. The description does not add any parameter meaning beyond what the schema provides, so the 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 names a specific verb and resource: checking whether a phone number has a WhatsApp account. It is clearly distinct from sibling tools like get_contact_info or get_contacts, though it does not explicitly differentiate itself from them.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites such as needing a connected instance, nor does it exclude cases covered by other 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 disclose that this is a non-read-only, non-destructive, non-idempotent, closed-world operation. The description adds meaningful context that credentials are validated via getStateInstance, but it does not explain session persistence, failure behavior, or what 'connect' actually changes, so 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?

Three short sentences with zero waste, and the prerequisite instruction is front-loaded after the core purpose.

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 three-parameter tool with full schema coverage and annotations, the description covers purpose, ordering, and credential validation. Minor gaps around QR/authorization flow and post-connect state keep it from being 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?

Schema description coverage is 100%, so all three parameters are fully documented in the schema. The description adds no parameter-level meaning beyond what the schema provides, making the baseline 3 correct.

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 ('Connect a WhatsApp instance') and adds the prerequisite role ('Call this before using other tools'). It does not explicitly differentiate from siblings like create_instance, get_state, or disconnect, so it falls short of a 5.

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

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

Gives clear context: call this before using other tools. It does not name alternatives, specify when not to use it, or clarify whether create_instance must come first, which keeps it at 4 rather than 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=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing further — no note that this creates persistent state on the WhatsApp instance, that repeated calls may create duplicate groups (non-idempotent), or what the call returns.

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

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

A single short sentence with no wasted words and the action front-loaded. However, brevity here is under-specification rather than disciplined concision — there is room for a sentence or two of genuine value.

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 non-idempotent, open-world mutation requiring three inputs, the description omits whether the instance must be connected, what happens to the participant list, and what the response contains (group ID). There is no output schema, so the description should have said something about 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?

Schema description coverage is 100%, so all three required parameters (instance_id, group_name, chat_ids with example format) are fully documented in the schema. The description adds no meaning beyond that, which is the expected baseline when the schema does the work.

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

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

The description is effectively a restatement of the tool name 'whatsapp_create_group' — verb 'Create' plus resource 'WhatsApp group'. It does not add specificity such as what is required to create one, what identifiers come back, or how it differs from siblings like whatsapp_add_group_participant.

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 context, no prerequisites (e.g., instance must be connected), and no mention of the related sibling tools such as whatsapp_add_group_participant or whatsapp_leave_group. The agent must infer everything from the name alone.

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, idempotentHint=false, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond naming the API — it does not warn that repeated calls create duplicate instances (non-idempotent), nor what the call returns (instance ID, token, QR?) that the agent needs to proceed.

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 no filler. It is efficient, though its brevity is partly the source of the missing behavioral detail rather than a virtue in itself.

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

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

With no output schema, the description should explain what creation yields (instance ID, token, QR state) since the agent needs that to chain into connect/get_qr. It also omits the non-idempotency implication. For a creation tool in a multi-step workflow, this is a meaningful 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 coverage is 100% with a single well-described partner_token parameter, so the schema carries the semantics. The description adds no extra meaning about the token's scope or format, which is acceptable at this coverage level.

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 ('Create a new WhatsApp instance') and names the backing API, which distinguishes it from siblings like whatsapp_get_instances and whatsapp_delete_instance. It does not, however, clarify how it relates to whatsapp_connect or whatsapp_get_qr, which an agent would need to sequence correctly.

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

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

There is no guidance on when to use this versus whatsapp_connect or whatsapp_get_instances, nor any stated prerequisite beyond the token in the schema. The agent must infer that instance creation precedes connection and QR retrieval.

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, idempotentHint=false and openWorldHint=true, so the safety profile is covered elsewhere. The description adds only the API/auth context ('Partner API'), and says nothing about irreversibility, what data is lost, or whether the phone number/instance channel survives — meaningful gaps for a destructive 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?

One sentence, front-loaded with the verb and resource, with no filler. Nothing in it is redundant.

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

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

For a two-parameter destructive tool with full annotation coverage and no output schema, the definition gives an agent enough to call it correctly. The remaining gap is consequence disclosure — nothing states that the instance is permanently removed — but annotations partly backfill 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 required parameters carry their own descriptions (instance_id, partner_token), so the schema does the work. The description contributes nothing additional about parameter formats or where to source values, which is the expected baseline.

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 a WhatsApp instance') plus the API surface it targets, so the operation is unambiguous. It does not, however, distinguish itself from near-neighbours like whatsapp_disconnect or whatsapp_logout, which an agent could plausibly confuse with deletion.

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

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

Usage is implied by the verb — an agent would reach for this to remove an instance permanently — but there is no explicit when-to-use/when-not guidance and no mention of the alternatives (disconnect vs logout vs delete) that appear as siblings. The routing decision is left to inference.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — notably it omits whether deletion is irreversible, whether it applies only to messages the caller sent, and what happens on an invalid message 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 words with zero waste and the action is front-loaded, but the brevity is under-specification rather than disciplined conciseness — there is no second sentence to earn its place because there is nothing here.

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

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

For a destructive, non-idempotent mutation with no output schema, the description should say what is destroyed, whether it is recoverable, and what a success response looks like. None of that is present, leaving the annotations and schema to carry the entire burden.

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% across all three required parameters (chat_id, id_message, instance_id), so the schema already carries the parameter documentation. The description contributes no additional meaning, but the baseline of 3 applies when the schema does the heavy lifting.

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 is 'Delete a message', which merely restates the tool name 'whatsapp_delete_message' and its annotation title 'Delete Message'. It names no scope (delete for everyone vs. delete for me only) and gives no way to distinguish it from siblings like whatsapp_edit_message or whatsapp_delete_notification.

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 alternatives, no mention of prerequisites (e.g., needing a valid instance_id and that the instance be connected), and no exclusions. The agent must infer all usage conditions from the name alone.

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, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds real context by framing the deletion as a queue acknowledgement rather than data destruction, but says nothing about failure modes (e.g., deleting an already-consumed receipt) or whether the notification is re-delivered.

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

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

A single short sentence with the core action front-loaded and a compact clarifying parenthetical. No filler, nothing to trim.

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 full schema coverage and annotations carrying the destructive/idempotency signals, the definition is minimally sufficient. It still leaves the agent guessing about sequencing (must it follow receive_notification?) and post-delete behavior, which matter for a non-idempotent destructive call.

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 itself documents receipt_id as the receiptId from receiveNotification, so the description carries no additional burden. It adds no syntax or format detail beyond what the properties already state, which is the baseline 3 for a fully documented 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 a notification from the queue") and adds the clarifying gloss "acknowledge receipt," which disambiguates it from whatsapp_receive_notification. It is clear what the tool does, though it does not name the sibling counterpart explicitly.

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

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

The parenthetical "(acknowledge receipt)" implies the usage context — call it after receiving a notification — but the description never states when to call it, what happens if the receipt was already acknowledged, or points at whatsapp_receive_notification as the source of receipt_id. Usage is inferred 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?

Annotations already declare readOnly=false, destructive=false, idempotent=false, and the description adds one genuinely useful fact beyond them: credentials are removed from the session. It does not say whether the instance record survives, whether reconnect is required to restore service, or whether in-flight messages are affected — the practical questions for an agent calling a non-idempotent session 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?

A single tight sentence with the action front-loaded and the credential-removal consequence appended. No filler, nothing to trim.

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, no-output-schema tool with annotations covering the safety profile, the definition is minimally adequate. The missing piece is sibling disambiguation against whatsapp_logout and whatsapp_delete_instance, which is the main way an agent could misuse this 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?

Only one parameter, instance_id, and the schema already documents it at 100% coverage. The description adds no format, sourcing, or validity detail (e.g. how to obtain the ID via whatsapp_get_instances), so the baseline 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?

States a specific verb and resource ("Disconnect a WhatsApp instance") plus the side effect of removing session credentials, so the action is unambiguous. However, it offers no differentiation from close siblings like whatsapp_logout, whatsapp_delete_instance, and whatsapp_connect, which an agent must distinguish before choosing.

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 instead of whatsapp_logout (also a session-terminating operation) or whatsapp_delete_instance (which presumably also invalidates the instance). No preconditions, no exclusions, and no statement about what happens to the instance record afterwards.

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, idempotentHint=false, openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it doesn't say the original text is overwritten (not versioned), that edits may be time-limited on WhatsApp's side, or what happens on failure.

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?

Five words, front-loaded, zero waste. It is appropriately sized for a short entry, though the terseness tips into under-specification rather than efficient completeness.

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?

A destructive mutation with no output schema needs its description to cover failure modes and edit constraints, and this one covers none. The schema documents the parameters adequately, but an agent still lacks the information to call this correctly in edge 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 100% and all four parameters carry their own descriptions, so the schema does the heavy lifting. The description contributes no additional meaning, such as whether id_message must belong to the same chat_id/instance_id, which is the baseline-3 outcome.

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?

A specific verb (Edit) plus specific resource (a previously sent message) – unambiguous, and implicitly separated from the sibling write tools send_message and delete_message. It stops short of naming those siblings or clarifying what 'edit' means at the WhatsApp level.

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 on when to choose edit over send_message or delete_message, no prerequisites, and no mention of the well-known WhatsApp restriction that only your own messages and only within a short window can be edited. The agent must infer all of this.

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, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — it does not say whether forwarding duplicates or moves content, whether it requires the source and destination chats to be on the same instance, or what happens with invalid message IDs.

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

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

A single short sentence with zero filler and the action front-loaded. However, its brevity reflects under-specification rather than efficiency — it spends no words on the source/destination pairing that defines the operation.

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

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

For a destructive, non-idempotent, cross-chat mutation with four required parameters and no output schema, the description is thin. It omits preconditions (connected instance, valid source chat) and result behavior, leaving the agent dependent entirely on the schema and annotations.

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 each of the four parameters documented (destination chat ID, source chat ID, message IDs, instance ID). The description adds no semantics beyond the schema, which is the expected baseline when the schema already does the work.

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

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

States a specific verb ("Forward") and resource ("messages") with a clear destination scope ("to another chat"). An agent can distinguish this from send_message, but the description does not explicitly name that distinction, so it falls short of full sibling differentiation.

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 on when to forward versus sending a new message, and no stated prerequisites such as the instance needing to be connected or the message IDs needing to exist in the source chat. The agent must infer the entire usage context from the parameter 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, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not say whether the code is returned in the response or dispatched to the phone, whether it expires, or whether requesting it has an outward-facing effect (e.g. sending an SMS/WhatsApp message) that the readOnly framing might lead an agent to underestimate.

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

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

A single short sentence with no filler, and the resource being fetched is front-loaded. It is efficient but arguably under-written given the ambiguity it leaves, so it stops short of a 5.

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?

A two-parameter read tool with full schema coverage and annotations is close to self-describing, but the critical ambiguity remains unresolved: whether the authorization code comes back in the response or arrives on the phone, and whether the instance must already exist/be paired. With no output schema, the description should have closed 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 coverage is 100% and the schema documents both parameters including a phone-number format example, so the description needn't restate them. It adds no meaning beyond the schema — the phrase "by phone number" merely echoes the phone_number property.

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 pairs a specific verb ("Get") with a specific resource ("authorization code for sign-in") and adds the scoping qualifier "by phone number." That is enough to know what the tool returns, but nothing distinguishes it from near neighbours such as whatsapp_get_qr or whatsapp_check_whatsapp, which are also part of the sign-in/connection flow.

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

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

There is no statement of when to call this instead of whatsapp_get_qr, whatsapp_check_whatsapp, or whatsapp_connect, nor any prerequisite such as the instance needing to be connected first. The agent must infer the sequencing of the auth flow entirely from the 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, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds no behavior beyond that — no message ordering, no pagination/cursor behavior, no note that history may be truncated to recent messages, and no hint about what each message entry contains.

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

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

Two short sentences, front-loaded with the operation, with zero filler. The second sentence duplicates schema content, which slightly weakens its value but does not bloat the definition.

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 only 3 flat parameters and rich annotations, the description is minimally adequate. But with no output schema, the agent gets no information about return shape, message ordering, or whether history is complete or windowed — the main open question for a history-fetching 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 coverage is 100%, so the schema already documents instance_id, chat_id formats, and the count default/max. The description's 'default 50, max 100' merely restates the schema, adding no new semantics. Baseline 3 is correct.

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: 'Get chat message history.' An agent knows exactly what it retrieves. However, it does not distinguish itself from close siblings like whatsapp_read_chat, whatsapp_get_message, or whatsapp_last_incoming_messages, so the differentiation bar for a 5 is not met.

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 only guidance concerns response size ('use a small count'), which is parameter tuning, not when-to-use. There is no statement of when this is preferable to whatsapp_read_chat or the last_incoming/last_outgoing siblings, and no prerequisites such as needing a connected instance.

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, idempotentHint, non-destructive and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: no return format (image URL, base64, binary?), no fallback behavior when the contact has no avatar, no note on whether a connection/auth is required.

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 no filler. It is efficient, though its brevity edges into under-specification rather than being a model of compactness.

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

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

With no output schema, the description is the only place to explain what is returned (an image URL? binary payload? null if absent), and it omits that entirely. For a lookup tool whose whole value is the returned avatar, this is a meaningful 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 coverage is 100%, so both parameters are documented, and the schema already says chat_id is a 'Contact or group ID'. The description's phrase 'of a contact or group' confirms group IDs are accepted but adds little beyond the schema — baseline 3.

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 ('Get') and resource ('avatar of a contact or group'), which is clearly distinct from siblings like whatsapp_get_contact_info or whatsapp_get_group_data. It stops short of explicitly differentiating itself from those tools, so it lands at 4 rather than 5.

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

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

There is no guidance on when to call this versus whatsapp_get_contact_info or whatsapp_get_group_data, no prerequisites (e.g., contact must exist, instance must be connected), and no exclusions. The agent must infer all of that.

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, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered structurally. The description adds nothing beyond that — not whether unknown IDs error or return empty, nor what fields 'information' comprises.

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 no filler. It is appropriately terse, though the brevity reflects under-specification rather than economy of useful 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?

For a two-parameter, read-only lookup with no output schema, the definition is minimally viable. Still, it never says what information is returned or how results differ from the sibling contact/group getters, which is the main ambiguity an agent would face.

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 chat_id documented as 'Contact or group ID' and instance_id as 'WhatsApp instance ID'. The description's phrase 'contact or group' merely restates the schema, so the baseline 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?

States a specific verb (get) and resource (information about a contact or group), so the basic operation is unambiguous. However, it does not differentiate from close siblings like whatsapp_get_contacts, whatsapp_get_group_data, or whatsapp_get_contact_avatar, leaving the agent to guess which getter returns what.

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 on when to use this versus whatsapp_get_contacts (list) or whatsapp_get_group_data (group details), and no prerequisites or exclusions are given. The agent must infer selection from the name alone.

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, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds nothing beyond that — no return shape, no indication of whether the list is paginated, cached, or requires an active session, which is the remaining burden for a bare read.

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 short sentence with no waste, but its brevity stems from under-specification rather than disciplined editing. It is front-loaded but carries almost no information.

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 single-parameter read tool with full annotation coverage and no output schema, the description does just enough for an agent to call it correctly. The main missing element is an explicit statement of what the list contains or how it relates to the per-contact sibling tools.

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?

Only one parameter (instance_id) exists and schema description coverage is 100%, so the baseline is 3. The description adds no meaning about the parameter beyond what the 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 phrase 'Get the contact list' names a verb and a resource, so the basic purpose is legible. However, with siblings like whatsapp_get_contact_info and whatsapp_get_contact_avatar present, the description never explicitly states that this returns the full list rather than details of one contact, leaving the distinction to inference.

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 over whatsapp_get_contact_info or whatsapp_get_contact_avatar, and no prerequisites such as the instance needing to be connected. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing what the response contains (members, name, invite link), but says nothing about failure modes (invalid group_id, not a participant) or that an invite link is a sensitive, shareable output.

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 clause with zero filler, and the returned fields are grouped parenthetically. It is terse to the point of under-specification, but nothing is wasted.

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

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

For a two-parameter read-only getter with 100% schema coverage, rich annotations, and no output schema, the description supplies the one missing piece: what data comes back. An agent has everything needed to select and call it.

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

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

Schema description coverage is 100% and both parameters (group_id with format example, instance_id) are documented in the schema itself. The description adds no additional parameter meaning, 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?

Specific verb ('Get') plus resource ('group data') with the returned fields enumerated (members, name, invite link), which distinguishes it from the group-mutation siblings like whatsapp_add_group_participant and whatsapp_leave_group. It doesn't name a competing read sibling (e.g. whatsapp_get_contact_info), but no real ambiguity exists.

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

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

There is no explicit guidance on when to call this versus alternatives or what preconditions apply (instance must be connected, bot must be a group member). Usage is only inferable from the tool name and purpose.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered without the description. The description adds only the meaningful nuance that this is partner-scoped (listing across all instances under a partner account) rather than single-instance scoped; it says nothing about result size, pagination, or failure modes for an invalid token.

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?

One front-loaded sentence with no filler, and the key scope qualifier ('partner instances') appears immediately. It is efficient but so terse that it omits any operational detail rather than being optimally informative.

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 list operation with full schema coverage and complete annotations, no output schema is needed and the description covers the essential scope distinction. A mention of whether results are paginated or what an instance record contains would close the remaining 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?

There is a single parameter with 100% schema description coverage ('Partner Token from your GREEN-API dashboard'), so the schema already carries the semantics. The description adds no format, scope, or permission detail beyond what the schema states, 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?

States a specific verb and resource ('List all partner instances') and names the API surface ('GREEN-API Partner API'), which separates it from instance-scoped siblings like whatsapp_get_state or whatsapp_create_instance. It does not explicitly name a sibling it is not, so it stops short of a 5.

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

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

There is no guidance on when to call this versus the many other instance-related tools (create_instance, delete_instance, get_state), no prerequisites beyond the implied partner token, and no exclusions. The agent must infer usage from the name alone.

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, idempotentHint and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds nothing beyond that — no mention of what happens if the ID is unknown, whether the message must belong to the given chat, or the shape of the result.

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 padding. It is efficient but borders on under-specification given the tool's place among 40+ siblings.

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 full schema coverage, all-required params and complete annotations, the definition is minimally sufficient to invoke the tool. It stops short of explaining what a returned message contains or what happens on a miss, which matters since no output schema exists.

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 all three parameters are documented in the schema, so the baseline is 3. The description contributes no extra semantics about the interaction between chat_id and id_message or how the ID is formatted.

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 a message") scoped by ID, so the agent can tell it retrieves a single message rather than a list. It offers no differentiation from siblings that also return message content, such as whatsapp_get_chat_history or whatsapp_last_incoming_messages.

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 many message-reading siblings, and no prerequisites or exclusions are stated. The agent must infer from the name alone that this is for fetching one known message ID.

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 goes beyond annotations by detailing that the result contains both an image and a specific 'qrLink URL' leading to an 'official GREEN-API page with a full-size auto-refreshing QR code.' This provides rich, non-obvious behavioral context about the output format and reliability.

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 slightly lengthy due to the detailed instructions on markdown formatting, but every sentence is necessary to convey the full operational requirements of the tool.

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

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

The description is highly complete. It informs the agent what data to retrieve (image + link), why the link is important (auto-refresh), and how to deliver it (clickable markdown link), leaving no ambiguity for execution or presentation.

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

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

With 100% schema description coverage, the baseline is 3. The description only provides contextual clarity (linking the ID to 'instance authorization') rather than explaining the schema itself.

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

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

The description clearly states its purpose: to 'Get the QR code for instance authorization.' This is highly specific and immediately differentiates it from sibling tools like `whatsapp_connect` or `whatsapp_create_instance`.

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?

While it doesn't explicitly state sequencing (e.g., 'must call this before connect'), it provides a critical usage rule: the agent must 'Always include the qrLink' in its response to ensure user success. This dictates the required presentation of the result.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description contributes nothing further — no indication of what is returned, whether auth/connection is required, or how it behaves on an invalid instance_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?

Three words with zero waste, but the brevity comes from under-specification rather than disciplined editing. Nothing is front-loaded beyond the verb because there is nothing behind it.

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 1-parameter read tool with no output schema, the description should at minimum say what settings object comes back or how it relates to set_settings. Instead it leaves the return shape and its distinction from whatsapp_get_wa_settings entirely unstated.

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

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

There is a single required parameter, instance_id, and schema description coverage is 100% ('WhatsApp instance ID'), so the schema carries the semantics. The description adds no extra meaning, but the baseline of 3 applies when the schema does the work.

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

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

The description restates the tool name/title almost verbatim: 'Get instance settings' adds only the word 'instance' over the title 'Get Instance Settings'. It does not say which settings (proxy, webhook, behavior toggles) are retrieved, and it fails to distinguish itself from the sibling whatsapp_get_wa_settings, which plausibly overlaps.

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

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

There is no when-to-use guidance, no prerequisite (e.g., instance must be connected), and no mention of the alternative whatsapp_get_wa_settings or whatsapp_get_instances. The agent must guess between two similarly named settings getters.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description's real contribution is enumerating the possible returned states (authorized, notAuthorized, blocked, sleepMode), which is genuinely useful since there is no output schema, but it doesn't explain what those states mean or what an agent should do on each.

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?

One front-loaded sentence with no filler; the parenthetical state list is compact. It is slightly under-explained rather than bloated, but sizing is appropriate for a trivial read 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 one-parameter read tool with full annotation coverage and no output schema, the description covers the main unknown (the set of possible states). What's missing is only interpretive detail on those states, so it is nearly complete but not exhaustive.

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 is a single required parameter with 100% schema description coverage ('WhatsApp instance ID'), so the schema already carries the semantics. The description adds nothing about instance_id, which is the expected baseline case.

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?

Clear specific verb+resource: 'Get instance state', with the possible state values enumerated in parentheses. It doesn't distinguish itself from nearby siblings like whatsapp_get_instances or whatsapp_check_whatsapp, so an agent must infer which one returns instance 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?

There is no when-to-use guidance, no mention of alternatives such as whatsapp_check_whatsapp or whatsapp_get_instances, and no prerequisites. Usage is only implied by the tool name.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds scope ('name, description, etc.') but no behavioral context beyond that, which is acceptable given the annotation coverage.

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 wasted words. The use of 'etc.' introduces slight vagueness but keeps it brief.

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 read-only tool with a complete schema and rich annotations, so the essentials are covered. The unresolved overlap with 'whatsapp_get_settings' is a notable gap for correct tool selection.

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

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

Schema coverage is 100%, and the single parameter is fully documented in the schema. The description does not add meaning 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?

The description gives a specific verb and resource ('Get WhatsApp account settings'), which is clearer than the bare name. However, it does not distinguish this tool from the sibling 'whatsapp_get_settings', leaving ambiguity about whether this is a WhatsApp-specific variant or a duplicate purpose.

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

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

There is no guidance on when to use this tool versus 'whatsapp_get_settings', 'whatsapp_set_settings', or other retrieval siblings. The agent must infer usage from the name alone.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description's only added behavioral content is the default (60) and cap (1440) on the window, which is also present in the schema; it says nothing about how many messages come back, ordering, or what happens at the cap.

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 zero filler, and the resource and the window constraint are both front-loaded. Nothing could be removed without losing information.

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 read tool with rich annotations, the description is close to sufficient, but with no output schema it leaves the return shape unspecified — how many messages are returned, whether they are ordered, and whether there is any paging or truncation behavior. Those are the questions an agent would still have before calling it.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema, and the description merely repeats the same default/max values for 'minutes'. Baseline 3 applies — no syntax, format, or edge-case meaning is added beyond the structured fields.

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 ('Get recent incoming messages') plus the scope ('last N minutes'), which is enough to separate it from the sibling whatsapp_last_outgoing_messages by direction. It stops short of explicitly naming that sibling, so differentiation is inferred from the word 'incoming' rather than stated.

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

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

Usage is implied by the name and the time-window framing — an agent can guess this is the tool for polling recent inbound traffic — but there is no explicit when-to-use guidance, no exclusions, and no pointer to alternatives like whatsapp_get_chat_history or whatsapp_read_chat for older or per-chat retrieval.

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, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds the windowing constraint (default 60, max 1440) but says nothing about return ordering, volume, or pagination behavior for what could be a large message list.

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 the time window and bounds stated immediately; no filler or 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?

No output schema exists, so an agent gets no indication of the return shape (message fields, ordering, limits). For a simple two-parameter read tool this is tolerable, but the description does not fill the 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 coverage is 100%, so both parameters are fully documented with the same default and max values. The description merely restates the minutes window and adds no new meaning beyond the schema, which is the baseline-3 case.

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 ('Get recent outgoing messages') and its direction qualifier ('outgoing') implicitly distinguishes it from the sibling whatsapp_last_incoming_messages. It never names that sibling or any alternative explicitly, so it falls short of a 5.

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

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

Usage is only implied: an agent can infer this is the tool to check recently sent messages. There is no statement of when to prefer it over whatsapp_get_chat_history or whatsapp_get_message, and no exclusions.

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, idempotentHint=false, and openWorldHint=true, so the safety profile is covered structurally, but the description adds nothing: it does not say whether the action is irreversible, whether the caller's own membership is removed, or whether admin/instance state affects the outcome.

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?

One short phrase, front-loaded and free of waste, but the brevity reflects under-specification rather than tight authoring; it conveys no more than 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?

The schema and annotations are rich enough for the agent to construct the call, but for a destructive, non-idempotent group mutation the description should at minimum state irreversibility and who is removed. That guidance is 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 100% — group_id format (120363XXX@g.us) and instance_id are fully documented in the schema, so the baseline of 3 applies. The description contributes no additional meaning about either 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?

"Leave a WhatsApp group" restates the tool name almost word for word; it names the verb and resource but adds no scope, no effect, and no differentiation from siblings like whatsapp_remove_group_participant or whatsapp_get_group_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?

There is no statement of when to use this tool versus alternatives such as whatsapp_remove_group_participant (removing someone else) or whatsapp_create_group, and no prerequisites are mentioned. The agent must infer all routing from the name alone.

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, openWorldHint=true, and idempotentHint=false, so the risk profile is covered structurally. The description adds nothing beyond the annotations — it does not say what logout actually invalidates (session/token), whether the instance remains registered, or how to re-authenticate.

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 no filler. It is efficient, though brevity here comes at the cost of specification rather than being a virtue of clarity.

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

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

For a destructive, non-idempotent mutation with no output schema, the description says nothing about the resulting state, recovery path, or error conditions. The agent cannot predict what happens after calling it or what to do if the instance is already logged out.

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?

Only one parameter, instance_id, and schema coverage is 100% with its own description ('WhatsApp instance ID'). The description adds no semantics beyond the schema, so the baseline 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?

States a specific verb ('Log out') and resource ('the WhatsApp instance'), so the basic action is unambiguous. It does not distinguish itself from close siblings such as whatsapp_disconnect, whatsapp_delete_instance, or whatsapp_reboot, which an agent must differentiate on its own.

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 log out versus disconnect, delete the instance, or reboot. No prerequisites (e.g., must be connected first) or consequences (session invalidation, need to re-scan QR) are given, so the agent must infer selection.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description only restates the basic mutation and adds no context about effects, permissions, or how optional message-level marking behaves.

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 wasted wording. It is efficient, though its extreme brevity leaves useful nuance unstated rather than structurally flawed.

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

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

For a mutation tool with no output schema, the description is too thin: it does not explain whether all unread messages are marked or only a specific message when id_message is provided. An agent can infer the basic intent but lacks enough context to call it confidently in edge 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 100%, so the baseline is 3 even though the description does not explain parameters. The description does not clarify that id_message can target a single message rather than the whole chat, but the schema already documents this.

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: 'Mark chat messages as read.' This is clear enough for an agent to understand the operation, though it does not explicitly differentiate from related siblings such as get_chat_history or get_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?

The description gives no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as needing the chat to exist or being connected. Usage is only implied by the name and operation.

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, idempotentHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is partially covered. However, the description adds nothing beyond the annotations: it doesn't say whether the session drops, whether in-flight messages are lost, whether a QR re-scan is required, or how long the restart takes — all important for a disruptive 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?

A single short phrase with the verb front-loaded and zero filler. It is efficiently sized, though arguably too terse for a state-changing operation.

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, annotation-covered tool this is minimally sufficient — the agent knows what to call and with which ID. Missing are the operational consequences of a reboot (session loss, downtime, need to reconnect), which matter for correct invocation sequencing.

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 is only one parameter (instance_id) and schema coverage is 100%, so the schema fully documents it. The description adds no extra meaning about the identifier (e.g., where to obtain it via whatsapp_get_instances), so 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?

States a specific verb (reboot) and a specific resource (the WhatsApp instance), which an agent can read at a glance. It does not distinguish the operation from nearby siblings such as whatsapp_disconnect, whatsapp_logout, or whatsapp_connect, so the boundary between reboot and those alternatives is left implicit.

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 indication of when to reboot versus disconnect/logout/connect, nor any prerequisites such as an active session or whether the instance must be in a particular state. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive/closed-world, so the safety profile is covered. The description adds the useful fact that this is a manual pull from a queue, but leaves unanswered what happens when the queue is empty (null return, error, blocking call) — critical behavior for a polling 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?

One short front-loaded sentence with no filler; the parenthetical is slightly cryptic but earns its place by disambiguating the pull model.

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, so the description is the only place to learn what a returned notification looks like and what an empty queue yields. Neither is covered, which leaves the agent unable to handle the most common polling outcome 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?

With a single parameter at 100% schema description coverage, the schema already documents instance_id fully. The description adds nothing about the parameter, 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?

"Get one notification from the queue" gives a specific verb and resource and makes the single-item, queue-draining semantics explicit. It is clearly distinguishable from whatsapp_delete_notification and the *_messages siblings, though it doesn't name them.

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

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

"(manual polling)" signals the consumption model but not the conditions: nothing says when to call this versus whatsapp_delete_notification to acknowledge, how often to poll, or how it relates to the message-history tools. Usage is implied 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the mutation profile is covered. The description confirms the effect is limited to revoking admin rights (the participant stays in the group), but adds nothing about permission requirements, reversibility, or error conditions for a destructive 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?

A single six-word sentence, front-loaded with the verb and effect. Nothing redundant or padded.

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 three-parameter mutation with fully described schema and rich annotations, the description is minimally adequate. However, for a destructive admin-level operation it omits prerequisites (caller privilege, connected instance) and the fact that failure occurs if the target is not an admin, leaving gaps an agent would want covered.

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

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

Schema description coverage is 100% with all three required parameters (instance_id, group_id, participant_chat_id) documented including ID formats, so the baseline of 3 applies. The description adds no additional meaning, such as that participant_chat_id must currently be an admin.

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 ('Revoke') and resource ('admin rights') scoped to 'a group member', which clearly separates it from the sibling whatsapp_remove_group_participant (removes membership) and whatsapp_set_group_admin (grants). The distinction from set_group_admin is only implicit via the tool name, not stated in prose.

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 when-to-use guidance, no mention of alternatives, and no prerequisites such as the caller needing to be an admin of the group or the instance needing to be connected. An agent must infer all conditions for safe use.

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 annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it doesn't say the removal is irreversible, that admin privileges are required, whether the removed participant is notified, or what happens if the participant isn't in the group. With annotations present the bar is lower, but zero added context earns only a 2.

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

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

A single tight sentence with no filler, front-loading the action and resource. It is well-formed but too thin to earn a 5 given how much decision-relevant information is absent.

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 destructive mutation with no output schema, and the description never covers authorization requirements, failure modes, or irreversibility. For a group-membership removal where a wrong call has real social consequences, that leaves material gaps for the agent.

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

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

Schema description coverage is 100% and the schema even supplies the expected chat ID format (79001234567@c.us). The description adds no parameter meaning 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?

States a specific verb and resource: removing a participant from a WhatsApp group. An agent can tell it apart from whatsapp_add_group_participant by polarity alone, but the description doesn't distinguish it from nearby siblings like whatsapp_remove_group_admin (which revokes admin status, not membership) or whatsapp_leave_group.

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 on when to use this versus whatsapp_remove_group_admin or whatsapp_leave_group, and no stated prerequisites such as the caller needing to be a group admin. The agent must infer all usage conditions from the name.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is covered elsewhere. The description adds nothing on top: it never warns that the card is delivered immediately to a live chat, that resending creates duplicates, or what a failure looks like.

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 no filler. It is efficient, though its brevity borders on under-specification for a six-parameter mutation 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 non-idempotent, destructive send operation with six parameters and no output schema, the description should say what the required instance_id/chat_id/phone_number triple represents and confirm immediate delivery. None of that is present, leaving meaningful gaps beyond what the annotations convey.

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 every parameter including the optional first_name/last_name/company fields is already documented in the schema. The description adds no meaning about how phone_number plus the optional name fields are assembled into the card, so the baseline 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 concrete verb and resource ('Send a contact card'), which distinguishes it from payload siblings like whatsapp_send_location, whatsapp_send_file and whatsapp_send_poll without opening their schemas. It does not, however, explicitly name those siblings or the target chat semantics.

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 choose this over whatsapp_send_message or the other send_* tools, and no prerequisites such as needing a connected instance or an existing chat. The agent must infer usage entirely from the tool name.

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

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

Annotations already declare destructive=true, readOnly=false, openWorld=true, and idempotent=false, so the bar is lower. The description adds essentially nothing on top: no mention that it posts into a chat irreversibly, no permission or instance-state requirements, no failure behavior for unreachable URLs. The "by URL" phrasing only restates the openWorld 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?

A single five-word sentence with zero padding and the key qualifier front-loaded. It is efficient, though the extreme terseness borders on under-specification rather than model 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?

For a 5-parameter destructive send tool with no output schema, the annotations cover the safety profile and the schema covers all parameters, so nothing critical is missing. Still, the description says nothing about side effects, caption handling, or result behavior, leaving it only minimally viable.

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

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

With 100% schema description coverage, every parameter including url, chat_id, instance_id, caption, and file_name is already documented in the schema. The description adds no extra meaning such as URL format, size limits, or how caption/file_name are applied, 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 gives a specific verb and resource ("Send a file") plus a discriminating qualifier ("by URL") that separates it from the sibling whatsapp_send_file_by_upload. It stops short of naming that sibling outright, but an agent can still route between the two.

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

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

Usage is only implied: the phrase "by URL" suggests this is the path when the file already lives at a remote address rather than on local disk. There is no explicit when-to-use, precondition, or mention of the alternative upload tool, so the agent must infer the split.

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, idempotentHint=false and openWorldHint=true, so the safety profile is carried elsewhere. The description adds only the transport mechanism; it says nothing about payload size limits, base64 encoding overhead, whether the send is irreversible, or what happens on partial failure — meaningful gaps for a destructive write.

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 the key differentiator in parentheses; nothing is wasted. It is arguably too terse rather than padded, which is a different failure than verbosity.

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 mechanics of the call are covered and annotations carry the safety profile, but for a destructive file-send with a required base64 payload, the description omits practical constraints (size limits, encoding expectations) that an agent needs before invoking it.

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

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

Schema description coverage is 100%, so every parameter (instance_id, chat_id, file_base64, filename, caption) is already documented in the schema. The description contributes no additional parameter meaning, which is the expected baseline when the schema does the heavy lifting.

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 file to a chat) and clarifies the mechanism: multipart upload with no separate URL step. The parenthetical implicitly distinguishes it from whatsapp_send_file/whatsapp_upload_file, though it never names those siblings outright.

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 'no separate URL step' phrasing implies this is the choice when file bytes are in hand rather than a remote URL, but usage is only implied. There is no explicit when-to-use/when-not or named alternative among the four sibling send/upload 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 annotations already say this tool mutates and is destructive (readOnlyHint=false, destructiveHint=true) and acts in the open world (openWorldHint=true). The description adds nothing: it doesn't say that the message goes to a chat, that sending can't be undone, which permissions or instance state are required, or what happens on failure. The three words 'Send a location' don't cover that 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?

The description is three words with zero filler, but it is front-loaded with nothing useful. This is under-specification rather than tight writing: there isn't a single sentence that earns its place by conveying information.

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 six-parameter mutation tool (four required) with no output schema. The annotations carry the safety profile, but the description never explains the target chat, the instance requirement, or the payload shape, so it is not complete enough for an agent to call this tool correctly on the description alone.

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 every parameter (instance_id, chat_id, latitude, longitude, name, address) is documented in the schema. Since the description mentions no parameter at all, baseline 3 applies: the schema carries the full load, and the description fills none of the gap.

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

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

The description 'Send a location' just restates the tool name and title verbatim, giving no more detail. Although it's technically possible to tell it apart from siblings like whatsapp_send_message or whatsapp_send_contact from the name alone, the description adds nothing beyond that label — for example, it doesn't say whether this sends a WhatsApp native location 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 no guidance on when to use this tool rather than alternatives such as whatsapp_send_message or whatsapp_send_contact. There is no mention of prerequisites, no mention that it needs a connected instance, and no exclusions — an agent must infer everything from the tool name.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond them: no mention that a sent message cannot be recalled, no rate/anti-ban limits, no requirement that instance_id refer to a connected instance. For a destructive, non-idempotent mutation the description contributes zero extra signal.

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 no filler. It is efficient but arguably under-specified rather than deliberately tight; there is room for one clause of usage guidance without bloat.

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 5 parameters, full schema coverage, and no output schema, the mechanical information is present. However, for a destructive messaging action the description omits the operational prerequisites (connected instance, chat ID format caveats) and the fact that sends are irreversible, leaving a meaningful 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%, including formats for chat_id (user vs group JID), so the schema carries parameter meaning. The description adds no additional semantics such as how quoted_message_id interacts with the message body. 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?

Specific verb+resource ("Send a text message via WhatsApp") that distinguishes it from media siblings like whatsapp_send_file, whatsapp_send_location, and whatsapp_send_contact. It stops short of naming those siblings explicitly, so differentiation is inferred 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 description gives no when-to-use context, no prerequisites (e.g. an instance must be connected and in a valid state), and no routing hints toward the other send_* tools. An agent must infer entirely from the tool name which send variant to pick.

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=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — no mention that the poll is posted immediately and visibly to the chat, whether it can be recalled, or what happens on failure, which is a notable gap for a destructive, non-idempotent send.

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, but it is under-specified rather than genuinely concise — there is no structure or detail to speak of.

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 5-parameter, 4-required, destructive write with no output schema, and the description gives no information on poll constraints, recipient scope (group vs. individual chat_id), or result behavior. An agent could call it, but only by leaning entirely on the schema and annotations.

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 every parameter including options and multiple_answers is documented in the schema. The description contributes no additional semantics such as limits on the number of options or how multiple_answers behaves, 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 and resource ('Send a poll') and is clearly distinguishable from siblings like whatsapp_send_message, whatsapp_send_location, and whatsapp_send_contact. It stops short of naming those siblings or the scope of the send, but the purpose is 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 versus whatsapp_send_message or the other send_* tools, and no prerequisites or exclusions are stated. The agent must infer that 'poll' implies structured options rather than free text.

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 annotations already indicate this is a non-read-only operation and potentially complex (`openWorldHint: true`). The description adds no unique behavioral context beyond stating 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?

It is a single, highly focused sentence that wastes no words. It is appropriately sized for a simple action.

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?

While it is complete regarding the *action*, it lacks completeness regarding the *context* of that action (e.g., validation checks, necessary permissions), which is a common gap for mutation tools.

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

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

With 100% schema description coverage, the schema already documents all parameters. The description does not add significant meaning beyond the action it describes, meeting the baseline score for schema-rich 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 uses a specific verb ('Promote') and a target resource ('group member'), making the purpose immediately clear to the agent.

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 provided regarding prerequisites, such as whether the caller must already be an admin, or any constraints on who can be promoted.

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 flag destructiveHint=true, idempotentHint=false, and openWorldHint=true, so safety is partly covered. The description adds nothing beyond that: it never says whether omitted parameters are preserved or reset, whether changing webhook_url invalidates an existing token, or that delays/webhooks affect live message delivery. For a destructive 10-parameter mutation, that silence is a real 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?

A single short sentence with the verb and resource front-loaded — no padding. The trade-off is that the brevity comes from hedging ('etc.') rather than from precision.

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 10 parameters, destructive semantics, and no output schema, the description should explain partial-update behavior and consequences of toggling webhooks, and it should not cite a nonexistent 'proxy' setting. What remains is a bare label, insufficient for an agent to call this safely.

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 every parameter is already documented and the baseline is 3. The description's only contribution is naming 'webhooks' as a category, and it introduces 'proxy' which has no corresponding parameter, so it does not meaningfully enrich semantics.

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

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

States a specific verb and resource ('Update instance settings') and names example setting groups, which separates it from the read-only siblings whatsapp_get_settings and whatsapp_get_wa_settings. However, the parenthetical cites 'proxy', which is not among the schema's properties, so the scope sketch is partly inaccurate.

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

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

There is no statement of when to use this versus the sibling read tools or when not to use it; the pairing with get_settings must be inferred from the tool names alone. No prerequisites (instance must be connected) or side-effect warnings are given.

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

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

Annotations already declare non-read-only, non-idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds the useful fact that files land in GREEN-API storage and a URL comes back, but omits practically important traits for a base64 upload: size limits, whether repeated uploads of the same file duplicate storage, and any expiry of the returned URL.

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, no filler. The purpose is front-loaded and the follow-up action is stated immediately after, which is the right order for an agent scanning for callability.

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

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

With no output schema, the description correctly compensates by stating that a URL is returned, and it names the next tool in the chain. Only the practical upload constraints (payload size) are missing for an otherwise simple three-parameter, fully documented 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 100%, with filename, file_base64 and instance_id all documented inline, so the baseline is 3. The description adds no parameter-level detail such as size ceilings on file_base64 or how filename affects the stored object.

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 (upload a file to GREEN-API storage) plus the observable outcome (returns its URL). It distinguishes itself from the send-side siblings by naming whatsapp_send_file as the consumer, though it never mentions whatsapp_send_file_by_upload, which overlaps most directly.

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

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

Gives a clear workflow hint ('Use the returned URL with whatsapp_send_file'), which implies when this tool is appropriate. However it gives no exclusion criteria and does not address whatsapp_send_file_by_upload, so an agent cannot tell from this text whether a two-step upload+send is ever preferable to the combined tool.

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