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

Annotations already declare destructive=false and idempotent=true, so the safety profile is largely covered. The description nonetheless adds real value beyond them: it discloses that archiving is account-scoped, non-lossy (messages retained), and reversible, and that the call returns a success confirmation. That is meaningful behavioral context a caller cannot derive from the annotations.

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

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

Three short sentences, front-loaded with the action, followed by scope and reversibility, then the return note. Nothing is redundant and no sentence can be cut 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 two-parameter, no-output-schema tool, the description covers action, state semantics, reversibility, scope, and the return behavior. Nothing an agent needs to invoke it correctly is missing, and there is no output schema demanding further explanation.

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%: 'chatId' is documented as a Chat JID and 'archived' as the archive/unarchive flag. The description merely restates the boolean toggle and adds no format, default, or edge-case guidance (e.g., what happens if already archived). Baseline 3 is appropriate 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?

States a specific verb ('archive or unarchive') and resource ('a chat'), and even covers the bidirectional toggle within the title-style opening. It does not, however, explicitly distinguish itself from adjacent siblings like whatsapp_pin_chat, whatsapp_mute_chat, or whatsapp_clear_chat, which an agent could plausibly confuse with it.

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 clause 'Archiving only hides it from the main list on this account; messages are kept and it can be undone' implies when this is appropriate (decluttering without data loss), but there is no explicit when-to-use, when-not-to-use, or named alternative such as pin_chat or delete_chat. 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 cover safety (idempotentHint=true, destructiveHint=false, readOnlyHint=false), and the description adds genuinely new behavioral context: the blocked party is not notified, and the action is reversible via whatsapp_unblock_contact. It does not discuss rate limits or how blocking an already-blocked contact behaves, but it covers the key consequences an agent needs.

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

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

Three short sentences, each earning its place: the action, the consequence, the reversibility, and the return shape. The core action is front-loaded with no filler.

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

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

For a single-parameter mutation with a clear annotation profile and no output schema, the description covers action, effect, notification behavior, reversibility, and return value. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 100% for the single 'id' parameter, and the description merely echoes the JID concept ('by user JID') without adding format or validation detail beyond the schema. Baseline 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?

States a specific verb and resource ('Block a contact by user JID') and immediately describes the effect: they can no longer message or call, and are not notified. This distinguishes it cleanly from the sibling whatsapp_unblock_contact, which it names 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 description names the reversing operation (whatsapp_unblock_contact) and states reversibility, giving clear context for when this action can be undone. It does not state explicit when-not conditions or prerequisites (e.g., whether the contact must exist first), so it stops short of a 5.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), and the description reinforces it with 'Read-only' while adding genuinely useful input-format constraints ('country code, digits only') and return shape ('registered, with its user JID'). It does not cover rate limits or batching limits, but it adds real behavioral context beyond the annotations.

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

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

Three short sentences, front-loaded with purpose, then format, then return value. Every sentence earns its place with no filler.

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

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

For a single-parameter read tool, the description covers purpose, input format, and return value; annotations carry the safety profile. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and there is only one parameter, so the baseline is already high. The description goes beyond the schema's generic 'List of phone numbers' by specifying the required format (country code, digits only), which is meaningful guidance an agent needs to invoke correctly.

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 ('Check many phone numbers at once for WhatsApp accounts') and the batch scope immediately distinguishes it from the single-number sibling whatsapp_check_user. An agent knows exactly what it does without opening the schema.

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

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

The phrase 'many phone numbers at once' clearly implies the batch use case versus the singular check tool, giving a solid selection signal. It stops short of explicitly naming whatsapp_check_user as the alternative or stating exclusions, so it is clear context rather than full routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety profile is covered; 'Read-only' is redundant but consistent. The description adds real value beyond annotations by disclosing the return semantics (registration status and user JID), which matters since there is no output schema.

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

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

Three short sentences, zero waste, with the primary action and the alternative routing both front-loaded. Nothing is padded or repeated.

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

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

For a single-parameter read tool with no output schema, the description covers purpose, precondition, input format, return values, and the alternative tool. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so baseline is 3, but the description adds a formatting constraint not present in the schema: pass the number with country code, digits only. The schema's example (1234567890) does not convey the country-code requirement, so this is genuine added meaning.

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 ('Check whether one phone number has WhatsApp') and explicitly scopes it to a single number, distinguishing it from the bulk sibling. An agent can tell it apart from whatsapp_bulk_check_users without opening either schema.

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

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

Gives the trigger context ('before sending to it') and names the alternative with its selecting condition ('For many numbers at once, use whatsapp_bulk_check_users'). Both when-to-use and when-to-use-something-else are covered.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is largely covered. The description adds useful behavioral context beyond annotations: 'cannot be undone' (explicit irreversibility), 'does not affect other participants' (blast radius), and 'Returns a success confirmation' (output signal). It does not mention auth or rate limits, and the return note is thin given there is no output schema, so it falls short of a 5.

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

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

Four compact sentences, with the core action front-loaded, followed by irreversibility/scope, alternative routing, and return behavior. Every sentence adds something and there is no filler.

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

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

For a single-parameter destructive chat operation with rich annotations and no output schema, the description supplies purpose, scope, alternative, irreversibility, and return shape. Nothing material an agent needs in order to call it correctly is missing.

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

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

There is only one required parameter and schema description coverage is 100%; the schema already documents 'chatId' as a 'Chat JID'. The description adds no additional format, syntax, or validation detail 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 states a specific verb and resource ('Delete all messages in a chat') and immediately clarifies scope ('keep the chat in the list'). It explicitly contrasts itself with the sibling 'whatsapp_delete_chat', so an agent can distinguish the two without opening schemas.

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

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

It gives an explicit alternative and the condition that selects it: 'To remove the chat entirely, use whatsapp_delete_chat.' It also notes the non-effect on other participants, which helps an agent decide when this narrow clear operation is appropriate versus full deletion.

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 the write/openWorld/non-idempotent profile, so the bar is lower. The description adds genuinely useful side-effect context the annotations cannot convey: participants are added immediately and notified, and the tool returns the new community JID. It stops short of describing approval/permission requirements.

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

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

Three short sentences, each earning its place: creation semantics, the side effect, and the return value. Front-loaded with the core 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?

With no output schema, naming the returned community JID is a valuable addition, and the immediate-notification side effect is covered. A note on whether approvalMode affects participant admission or any auth/prerequisite constraints would make it 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 coverage is 100%, so all three parameters are already documented, making 3 the baseline. The description reinforces that participants are optional and that the caller becomes admin, but adds no new semantics for approvalMode or the JID format.

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 community') and clarifies that the calling number becomes admin, which separates it from create_group and create_community_group. It does not explicitly contrast with those siblings, 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?

No when-to-use guidance and no exclusions or alternatives named, despite a dense sibling set that includes create_group, create_community_group, and link_group_to_community. The 'optionally adding participants' phrase only describes a capability, not a selection condition.

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

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

Annotations already declare readOnly=false, idempotent=false, destructive=false and openWorld=true. The description adds genuinely new behavioral context the annotations cannot: that supplied participants are actually added and notified, that admin rights are required for authorization, and that the JID is returned. It does not restate the safety/idempotency profile, which is fine since annotations carry it.

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

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

Three short sentences, front-loaded with the action and scope, then the routing alternative, then the return value. No filler or repetition of the tool name.

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

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

With no output schema, the description helpfully states the return value (new group JID). Combined with the auth requirement and alternative routing, an agent has everything needed to call this mutation correctly.

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

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

Schema coverage is 100%, so the schema already documents id (community JID), name, and participants (JIDs). The description adds the side-effect semantics of participants (added and notified) but no format or constraint detail beyond that, 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 (create) and resource (group inside a community), and explicitly distinguishes itself from whatsapp_link_group_to_community, which is the nearest sibling. An agent can route between the two without opening either schema.

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

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

Gives an explicit when-to-use-this vs. when-to-use-the-alternative clause ('To attach a group that already exists, use whatsapp_link_group_to_community'), plus a prerequisite ('Requires community admin rights'). Nothing material 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 a non-destructive, idempotent, open-world write, and the description adds genuine value beyond them: it discloses the upsert semantics (a name update when the contact exists, consistent with idempotentHint) and bounds the blast radius to this account's address book. It does not cover auth requirements or what happens to the optional firstName on update.

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

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

Two tight sentences with zero waste; the core action and its upsert nature are front-loaded, followed by scope and return confirmation.

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 three-parameter mutation tool with no output schema, the description covers the essential what, scope, and return signal ('success confirmation'), and annotations carry the safety profile. Only minor gaps remain, such as behavior of the optional firstName on an existing contact.

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 every parameter (id, fullName, firstName) is documented in the schema, so the baseline is 3. The description adds no parameter syntax, format, or required/optional detail beyond what the schema already states.

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 (save a contact) plus the upsert behavior (updates the name if it already exists), so the agent knows this is a create-or-update operation. It does not explicitly distinguish itself from the similarly named sibling whatsapp_send_contact, which also involves contacts, so differentiation is left 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?

The scope note 'Only affects this account's address book' implies the context of use and reassures the agent this is a local address-book write rather than a message send. However, there is no explicit when-to-use versus when-not-to-use guidance and no named alternative, so usage is only implied.

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-readOnly, non-idempotent, non-destructive, open-world. The description adds real context beyond that: participants are added immediately and notified (third-party side effect), calling twice creates two groups (concrete consequence of non-idempotency), and it returns the new group JID, which matters since there is no output schema.

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

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

Four short sentences, no filler, with the core action front-loaded and the side-effect/return-value caveats following. Every sentence earns its place.

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

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

Annotations cover the safety profile and the description supplies the return value plus the notification side effect, so an agent can call this correctly. Minor gaps remain: no handling guidance for invalid JIDs or failure behavior.

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 already documented. The description only restates 'participants (user JIDs)' and adds that the session number becomes admin, which is implicit behavior rather than parameter meaning — 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 and resource ('Create a new group') and adds scope detail — the calling number becomes admin and participants are the given user JIDs. This clearly separates it from siblings like whatsapp_create_community_group, whatsapp_create_newsletter, and whatsapp_create_contact.

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

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

No when-to-use guidance or alternative routing is given. The description never mentions when to prefer this over whatsapp_create_community_group, whatsapp_join_group_with_link, or the many group-management siblings; usage must be inferred 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 the write/open-world/non-idempotent/non-destructive profile, so the bar is lower. The description adds two genuinely useful facts beyond structured fields: that the channel becomes public immediately on creation, and that it returns the new channel JID.

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

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

Two compact sentences, front-loaded with the core action and followed by the consequence and return value. No filler or redundant restatement.

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, mentioning the returned JID is valuable, and the public-on-creation consequence covers the main non-obvious behavior for a mutation tool. A note on session/permission prerequisites would make it 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 coverage is 100%, so the schema already documents name, picture, and description. The description only restates that description and picture are optional, adding no format or syntax detail beyond what the schema provides. 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?

States a specific verb (Create) and resource (WhatsApp channel/newsletter), and resolves the terminology ambiguity by equating 'channel' with 'newsletter'. It also specifies ownership scope ('owned by this number'), which distinguishes it from read-side siblings like whatsapp_list_newsletters and whatsapp_get_newsletter.

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 'Create a new WhatsApp channel', but the description never states when to use this versus alternatives, nor any prerequisite such as requiring an active session. No exclusions or 'when not to use' guidance is provided.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds genuinely non-obvious behavior: the deletion is irreversible and is scoped to this account only, with other participants keeping their copy. It also notes the success-confirmation return, though that detail is minor.

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, front-loaded with the action and scope, followed by the irreversibility warning, the sibling disambiguation, and the return value. No filler or repetition.

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

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

For a single-parameter destructive tool with no output schema, the description covers what happens (chat and messages removed), scope of impact, reversibility, an alternative tool, and the return shape. Nothing an agent needs before invoking is missing.

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

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

One parameter (chatId) with 100% schema description coverage, so the schema already carries the semantics; the description adds nothing about the identifier format. Baseline 3 is appropriate when the schema fully documents the only 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?

States a specific verb and resource ('Delete a whole chat and its messages from this account') and scopes it precisely. It is immediately distinguishable from the related but different sibling whatsapp_clear_chat, which it names 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?

Provides an explicit alternative and the condition that selects it: 'To empty a chat but keep it in the list, use whatsapp_clear_chat.' An agent does not need to infer when to pick this tool over its closest sibling.

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

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

Goes well beyond the annotations: it discloses irreversibility ('cannot be undone'), the visible side effect for other participants, and the authorization scope (own messages or admin powers). This is exactly the 'what gets destroyed / auth needs' context the annotations alone do not supply.

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

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

Front-loads the action and warning, then the routing alternative, then the scope constraint. Dense and well ordered; only the trailing 'Returns a success confirmation' is low-value filler.

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

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

For a destructive tool with no output schema, it covers action, irreversibility, side effects, permissions, and the return signal. Nothing an agent needs to call it safely is missing.

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

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

Schema description coverage is 100%, so chatId, senderId, and messageId are already documented in the schema. The description adds no format or syntax detail beyond it, which matches the baseline 3 for fully covered schemas.

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 message for everyone) and immediately distinguishes itself from the sibling whatsapp_delete_message_for_me. An agent can tell these two apart without opening either schema.

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

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

Explicitly names the alternative and the condition that selects it ('To hide a message only on this account, use whatsapp_delete_message_for_me'). It also states the prerequisite for using this tool: own messages, or others' messages when acting as group admin.

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=true, and readOnlyHint=false. The description adds valuable context beyond those: it specifies the deletion affects only the current account, other participants still see the message, the action cannot be undone, and the tool returns a success confirmation.

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?

Four short sentences, front-loaded with the core scope, then effect, irreversibility, and alternative. Every sentence adds distinct, necessary information with no waste.

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 mutation tool with full schema coverage, complete annotations, and no output schema, the description covers all an agent needs: effect scope, side effects on others, irreversibility, sibling routing, and return confirmation.

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 fully documents all five parameters. The description adds no additional meaning or syntax for any parameter, 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?

The description states a specific verb (Delete), resource (a message), and scope (only on this account), and explicitly distinguishes itself from the sibling tool whatsapp_delete_message. An agent can immediately tell this deletes locally rather than globally.

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

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

It explicitly names the alternative tool (whatsapp_delete_message) and the condition for using it: 'To remove it for everyone, use whatsapp_delete_message.' It also clarifies the local-only effect, leaving no ambiguity about when to choose this tool.

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

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

The annotations already declare destructiveHint=true and idempotentHint=true, but the description adds valuable context beyond them: contacts stop seeing the status, the action cannot be undone, and it returns a success confirmation. It does not contradict the annotations.

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

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

Four short sentences, front-loaded with the core action and scope. Every sentence adds useful information about effect, reversibility, and return, with no waste.

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 one-parameter deletion tool with full schema coverage and clear annotations, the description is complete. It states the effect, irreversibility, and return confirmation; an output schema is not needed.

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 single messageId parameter is already documented in the schema. The description's phrase 'by its message ID' does not add format or syntax details beyond what the schema provides, making 3 the appropriate 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?

The description names a specific verb (Delete) and resource (a status this number posted) and scopes it by message ID. It is clearly distinguishable from sibling delete tools like whatsapp_delete_message because it targets statuses rather than chat 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?

It clearly frames the context: deleting a status that this number posted, by its message ID. However, it does not explicitly name alternatives or state when not to use this versus other deletion tools, leaving that 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 readOnlyHint=true and openWorldHint=true, so the explicit 'Read-only' line is redundant but consistent. The description adds useful return behavior: binary content with MIME type, which is not covered by annotations.

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

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

Two tightly written sentences with no wasted words. The purpose and return format are front-loaded.

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

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

For a one-parameter download tool with no output schema and annotations covering safety, the description supplies the key missing return information (binary content plus MIME type). It omits failure modes such as expired media, but is otherwise sufficient.

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

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

Schema description coverage is 100%, so the schema already defines 'id' as the media ID from a received message event. The description repeats this without adding format, sourcing, or validation details beyond the schema.

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

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

States a specific verb and resource: download the file attached to a received message. The phrase 'using media.id from the message event' and 'attached to a received message' clearly separates this from sibling send/get 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?

Gives clear context for use: a media file attached to a received message, keyed by media.id from the message event. It does not name exclusions or alternative tools, so it stops short of the top score.

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 this is a mutating, non-destructive, idempotent operation. The description adds valuable behavioral details beyond annotations: everyone in the chat sees the 'edited' mark, there is a ~15-minute time window, and it returns a success confirmation. It still does not describe what happens if the window has passed or the exact failure response.

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?

Four short sentences, front-loaded with the core action. Each sentence adds distinct information: what it does, visibility, time constraint, and return value. No wasted wording.

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 annotations and no output schema, the description covers purpose, side effects, key constraint, and return behavior. It does not explain failure modes (e.g., expired window) or the effect of optional parameters like mentions and ephemeralExpiration, leaving a minor completeness 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 60%, with 'to', 'text', and 'messageId' documented in the schema, while 'mentions' and 'ephemeralExpiration' are undocumented. The description adds no parameter-level meaning beyond referring to 'text', so it does not compensate for the two undocumented optional parameters.

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

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

The description states a specific verb and resource: 'Edit the text of a message this number sent.' It scopes the operation to messages sent by the authenticated number, which cleanly distinguishes it from sibling tools like whatsapp_send_text and whatsapp_delete_message without needing to 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?

It provides clear contextual guidance: the message must be one this number sent, and WhatsApp only permits editing for about 15 minutes after sending. It does not explicitly name alternatives (such as deleting and resending), but the conditions for valid use are clear.

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

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

With annotations covering the safety profile (non-read-only but non-destructive and idempotent), the description adds genuinely useful behavior: the messages are not returned and instead are emitted asynchronously to the event stream, and the call only yields an acknowledgement. This materially shapes how an agent must consume 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?

Three short sentences, each carrying distinct information: the action, the asynchronous delivery caveat, and the return shape. The critical caveat is front-loaded ahead of the return 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 zero-parameter, no-output-schema tool, the description is nearly self-sufficient: it explains the side effect, the asynchronous delivery channel, and the acknowledgement return. It could go further by relating to the history-sync lifecycle, but nothing essential for correct invocation is missing.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies no input is required; nothing is lost by the empty schema.

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

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

States a specific verb and resource ('Re-publish the history sync messages cached for this instance as events'), which is unambiguous. It distinguishes itself from the send/get/update siblings by nature of the operation, though it never names a sibling to contrast against.

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 or when-not guidance is given. The sentence about messages arriving through the event stream hints at the calling context but never states the condition under which an agent should invoke this versus requesting messages directly.

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

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

Annotations already carry readOnlyHint=true, so 'Read-only' is largely redundant, but with no output schema the statement 'Returns the blocked JIDs' usefully discloses the return shape. It does not cover ordering, pagination, or whether the list reflects a specific session, so it stops short of full disclosure.

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, front-loaded with purpose, followed by safety posture and routing, then return value. No filler or restated boilerplate.

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

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

For a zero-parameter read tool with no output schema, the description supplies purpose, safety profile, alternative routing, and the return type. Nothing an agent needs in order to call it correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no parameter meaning for the description to add or omit. Nothing in the description misleads about inputs.

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 the contacts this number has blocked'), which unambiguously separates it from the mutation siblings whatsapp_block_contact and whatsapp_unblock_contact. An agent can identify this tool without opening the schema.

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

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

Explicitly marks the tool as read-only and names the two alternative tools to use when the intent is to change the blocklist. That covers both the when-to-use and the when-not-to-use case with named siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so 'Read-only' is redundant. The description adds that it returns the chat object and enumerates fields like mute, pin, archive, and disappearing timer, which is useful context, but does not cover error behavior, auth needs, or rate limits.

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

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

Two tight sentences: the first front-loads purpose and key returned fields, the second adds read-only status and return shape. No wasted words.

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 read-only getter with one documented parameter and annotations covering safety, the description gives enough: what it returns and the main fields. It could be slightly more complete by noting error behavior for an invalid JID, but no output schema exists so explaining the return object is helpful.

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 only parameter chatId is documented as 'Chat JID'. The description restates 'by its JID' but adds no syntax or format detail 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 and resource: get details of one chat by JID. The phrase 'one chat' distinguishes it from the sibling whatsapp_get_chats, which lists multiple chats, and the field list names what is retrieved.

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?

Implies usage by requiring a single JID and being read-only, but does not explicitly say when to choose this over alternatives such as whatsapp_get_chats or when not to use it. No exclusions or prerequisites are stated.

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

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

Annotations already cover readOnlyHint and openWorldHint, but the description adds useful context beyond them: the tool only applies to business accounts (a real failure condition) and that it returns a profile object. 'Read-only' mildly restates the annotation, but the eligibility caveat is genuine added value.

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, front-loaded with the core action, then eligibility, then return shape. No filler and nothing redundant beyond the minor 'Read-only' restatement.

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 usefully names the fields returned and the business-account precondition. It could state what happens for a non-business chat (error vs empty), which is the only meaningful gap for a single-param read 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?

One parameter with 100% schema description coverage, so the schema already documents chatId. The description adds no format or syntax detail beyond what the schema provides, 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 (Get) and resource (WhatsApp Business profile of a chat) and enumerates the returned fields, which cleanly separates it from siblings like whatsapp_get_chat, whatsapp_get_my_profile, and whatsapp_get_user_profile.

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 precondition — 'Only business accounts have one' — which tells the agent when this call is applicable, and it implies the negative case. It stops short of naming an alternative tool for non-business chats, so it is not fully explicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, matching 'Read-only'. The description adds genuine behavioral context beyond those: it states the return content (picture URL and ID) and discloses failure modes ('fails if the chat has no picture or it is hidden by privacy settings'), which an agent cannot infer from annotations alone.

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

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

Three short sentences, front-loaded with the primary action, then read-only status, then return/failure behavior. No filler; every sentence earns its place.

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

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

With no output schema, the description compensates by naming the return values (URL and ID) and the failure conditions. Combined with annotations covering the safety profile, an agent has everything needed to call this correctly.

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

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

Schema description coverage is 100% for the single chatId parameter. The description's 'by its JID' slightly reinforces the expected identifier format but adds little beyond the schema's own 'Chat JID' description, 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 (Get) and resource (profile picture of a chat), and clarifies the resource is 'a contact or a group'. This clearly distinguishes it from write siblings like whatsapp_set_group_picture and whatsapp_set_community_picture.

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 read-only nature and resource are clear, implying straightforward usage, but the description offers no explicit guidance on when to use this versus alternatives (e.g., whatsapp_get_chat_business_profile or whatsapp_get_user_profile) and no prerequisites. 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 readOnlyHint=true and openWorldHint=true, so 'Read-only' merely restates structured data. The only added behavioral detail is the return shape ('the chats and their count'), with no mention of pagination, ordering, or volume limits for a listing call that could be large.

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 filler, front-loaded with the scope and immediately followed by the safety profile and the routing rule. Every sentence earns its place.

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

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

For a no-argument read-only listing tool with no output schema, the description covers scope, safety, the sibling alternative, and the return content. Nothing an agent needs to invoke it correctly is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for an empty schema applies. 'List every chat' correctly implies no filtering arguments are accepted.

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 every chat on the connected number') and scopes it ('both direct and group'). It also explicitly distinguishes itself from the sibling whatsapp_get_chat, so an agent can tell the two apart without opening a schema.

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

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

Gives an explicit when-to-use ('discover chat JIDs') and names the alternative with its selecting condition ('use whatsapp_get_chat for one chat's details'). This is exactly the when/when-not/alternative routing guidance the dimension asks for.

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

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

Annotations already declare readOnlyHint=true, so the 'Read-only' sentence largely restates structured data. The description does add value by naming the fields the community object carries, but it says nothing about failure behavior for invalid JIDs or the openWorldHint implications.

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 clauses, front-loaded with the action and identifier, no filler. Every sentence carries 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 schema coverage, annotations, and no output schema, this is nearly complete — the description even previews the return fields. Only marginal gaps remain (no guidance on invalid/stale JID behavior or routing versus sibling lookup 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?

Schema description coverage is 100% and the single parameter is fully documented as 'Community JID'. The description's 'by its JID' adds no syntax, format, or sourcing detail 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 (Get), resource (community), and the identifying key (JID), and enumerates what the returned object contains (name, description, settings, announcement group). This distinguishes it cleanly from siblings like whatsapp_list_communities and whatsapp_get_community_participants.

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 'by its JID' — the caller must already know the community identifier. There is no explicit statement of when to use this versus whatsapp_list_communities or whatsapp_get_community_sub_groups, nor any prerequisite guidance.

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

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

Annotations already establish this as a read-only, open-world call, so the bar is lower; the description still adds real value by disclosing the admin-rights requirement and the security implication that anyone holding the link can request to join. It stops short of covering failure modes (e.g., what happens if no link exists) or return format.

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?

Four short sentences with the action front-loaded and no filler. 'Returns the link' is mildly redundant with the opening sentence but also confirms the output in the absence of an output schema, so it roughly earns its place.

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

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

For a one-parameter, read-only lookup with no output schema, the description covers purpose, permission requirement, and the nature of the returned value. Adequate; only edge-case behavior and JID sourcing are left implicit.

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 'id' is documented as a Community JID, so the schema carries the load. The description adds no syntax, format, or source guidance for obtaining that JID; 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 (get the current invite link of a community), which clearly separates it from group/chat tools. It does not, however, explicitly name the nearest sibling (whatsapp_get_group_invite_link) or clarify the community-vs-group distinction for an agent scanning a long sibling list.

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

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

Provides a prerequisite ('Requires admin rights') but no when-to-use guidance relative to alternatives such as whatsapp_reset_community_invite_link or the group equivalents. 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 readOnlyHint=true and openWorldHint=true. The description only repeats the read-only nature and says it returns participants, adding no behavioral context such as pagination, rate limits, auth needs, or return format.

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 short and front-loaded with the main purpose, but the sentence 'Read-only' merely repeats the annotation and 'Returns the participants' is redundant with 'List the participants'. Every sentence does not fully earn its place.

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

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

For a simple read-only list operation with one documented parameter and safety annotations, the description is minimally adequate. However, with no output schema, it does not explain the return structure or what admin status values look like, leaving a 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% and the single parameter 'id' is documented as 'Community JID'. With full schema coverage, the baseline is 3 since the description adds no parameter meaning beyond what the schema already 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 gives a specific verb and resource: 'List the participants of a community, with their admin status.' It is clear what the tool does and implies the community scope, but it does not explicitly distinguish itself from the sibling group-participant 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 such as whatsapp_get_group_participants or other community-management tools. The description only states what it does, not when or why an agent should select it.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds return information (groups and their JIDs), but does not mention pagination, ordering, or error behavior for invalid community JIDs.

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

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

Three short, front-loaded sentences with no wasted words. The core action is stated first, followed by safety and return 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 read-only listing tool with one fully documented parameter and no output schema, the description covers the essential action and return content. It is nearly complete, though minor details like pagination or ordering are omitted.

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 documented as 'Community JID'. The description does not add syntax or format details beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: list groups linked to a community. It clearly distinguishes this tool from siblings like whatsapp_get_groups or whatsapp_get_community by scoping the result to a community's sub-groups.

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

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

The purpose implies when to use it: when an agent needs the groups belonging to a specific community. However, it does not name alternatives or state when not to use this tool versus related community/group listing tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so 'Read-only' merely restates structured data. The description does add that the returned object contains saved name, push name, and business name, but says nothing about failure modes for an unmatched JID despite openWorldHint implying external lookups.

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

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

Two short sentences with no filler, front-loading the identity and scope of the operation before the return note. Nothing extraneous, though also nothing especially well-structured.

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

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

For a single-parameter read tool with full annotation coverage and no output schema, the description covers identity, scope, and the main return fields. Only the not-found behavior is left unspecified, which is a minor gap at this complexity level.

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 documented parameter ('Contact JID'), so the schema already carries the semantics. 'By JID' adds no format, validation, or lookup detail beyond the schema description.

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

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

States a specific verb (Get) and resource (one saved contact), and enumerates the returned fields (saved name, push name, business name). The word 'one' implicitly distinguishes it from the sibling whatsapp_get_contacts, though it never names that sibling 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?

Usage is only implied by 'Get one saved contact by JID' — the single-lookup case. It never states when to prefer this over whatsapp_get_contacts, whatsapp_get_user_profile, or whatsapp_check_user, nor what happens for an unknown JID.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so 'Read-only' adds little. However, the description adds return-shape information ('Returns the contacts and their count') that is not available anywhere else, since there is no output schema. It still omits any pagination or volume behavior for potentially large contact lists.

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, front-loaded with what is listed and scoped before the routing hint and the return note. Every sentence earns its place apart from the slightly redundant 'Read-only'.

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

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

For a parameterless list tool, the description covers purpose, the relevant alternative, and the return shape, which is all an agent needs given the read-only annotations. No output schema means the return note is the right level of detail.

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

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

The tool takes zero parameters, so the baseline is 4; there is no parameter surface the description needs to compensate for. Nothing in the description misrepresents inputs.

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 the contacts saved on the connected number') and scopes it to the connected account, which separates it from account-agnostic siblings. It also explicitly names a sibling it is not (whatsapp_check_user), so an agent can route without opening schemas.

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

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

Provides an explicit alternative with the condition that selects it: 'To check whether a phone number has WhatsApp, use whatsapp_check_user.' It does not address when to prefer this over whatsapp_get_contact (single) or whatsapp_sync_contacts, so it stops short of full when/when-not coverage.

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 readOnlyHint=true and openWorldHint=true, and the description's 'Read-only' simply restates that. It does add the useful fact that the call returns a group object containing settings and participants, but discloses no auth, rate-limit, or failure behavior.

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

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

Two short sentences, front-loaded with the core action and the returned fields. Minor redundancy in the 'Read-only' sentence, which duplicates the annotation, but there is no padding.

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

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

For a single-parameter read tool with no output schema and annotations covering the safety profile, the description is essentially complete: it says what it fetches and what comes back. A bit more on failure modes or JID format would make it fully self-sufficient.

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

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

Schema coverage is 100% and the single 'id' parameter is already documented as 'Group JID' in the schema. The description's 'by JID' adds no syntax or format detail 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 ('Get') and resource ('details of a group') and enumerates the returned fields (name, description, settings, participants), so it is distinguishable from sibling listing tools like whatsapp_get_groups. It does not explicitly name a sibling, 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?

The phrase 'by JID' implies the lookup context, but there is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as whatsapp_get_group_info_from_link or whatsapp_get_groups. Usage is only implied.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description reinforces it and adds the meaningful side-effect disclosure that no membership is created ('without joining it'). It stops short of describing failure behavior (invalid/expired code, private group) under the open-world hint, so it is good but not exhaustive.

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

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

Three short, front-loaded sentences with the scope constraint and the no-join guarantee placed early. 'Returns the group info' is mildly redundant with the field enumeration in the first sentence, a small amount of waste.

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 naming the returned fields, and it discloses the side-effect boundary. What is missing is only error/edge-case behavior for an open-world fetch, which is a minor gap for a simple one-param read.

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 'code' parameter is documented as 'Invite link code'. The description echoes 'invite code' but adds no format, syntax, or validation detail 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+resource ('Preview a group from an invite code') and immediately clarifies the key distinction from join_group_with_link: 'without joining it.' It also lists the returned fields (name, description, size), so an agent can tell exactly what it gets without opening any schema.

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

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

The phrase 'without joining it' implicitly names the condition that separates this from the join_group_with_link/join_group_with_invite siblings, which is the most likely confusion. It does not explicitly call out an alternative or state when-not to use it, but the contextual routing is clear.

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

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

Annotations only declare that this is a read-only, open-world call. The description adds material behavior beyond that: the admin-rights requirement (authorization) and the security implication that anyone holding the link can join, plus confirmation of the return value.

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?

Four short sentences, all front-loaded and free of filler; the admin requirement and security caveat are placed early. The closing 'Returns the link' is mild restatement of the first sentence but not wasteful.

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 read-only getter with a single fully documented parameter and no output schema, the description covers the essentials: what it returns, the authorization requirement, and the join-security implication. Nothing critical is missing, though an explicit note on where to use the returned link would be a bonus.

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 ('id', Group JID) and the schema already documents it with 100% coverage, so the baseline is 3. The description adds nothing about the id format or which group identifier to pass.

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 the current invite link of a group'), and the word 'current' implicitly separates it from the sibling whatsapp_reset_group_invite_link. It stops short of explicitly naming that alternative, so it is clear but not maximally differentiating.

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

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

Provides one precondition ('Requires admin rights'), which is useful context for deciding whether the call can succeed. However, it gives no guidance on when to prefer this over resetting the link or fetching group info from a link, leaving the routing decision implied.

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 states 'Read-only', which simply restates readOnlyHint=true already present in annotations, and adds nothing about rate limits, permissions, pagination, or failure modes. With annotations covering safety, the description contributes no behavioral context beyond what structured data provides.

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

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

Three short, front-loaded sentences. The final sentence 'Returns the participants' largely duplicates the opening clause, so it is slightly redundant rather than wasteful.

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 one-parameter read tool with no output schema, the description is minimally adequate: it indicates the returned entities and their admin-status field. It omits any indication of result ordering or whether the caller is included, but nothing critical to invocation is missing.

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

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

There is a single parameter and schema description coverage is 100% ('Group JID'), so the schema already carries the semantic burden. The description adds no format or identifier guidance beyond it, making 3 the appropriate 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 ('List a group's participants') plus the payload detail ('with their admin status'), which cleanly separates it from write-side siblings like whatsapp_update_group_participants. It stops short of naming an alternative, but the purpose itself 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?

No when-to-use, when-not-to-use, or alternative tooling is mentioned. The agent must infer that this is the read counterpart to update_group_participants purely 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 cover readOnlyHint=true and openWorldHint=true, so the description's 'Read-only' is redundant, but it adds real value beyond the annotations: the admin-rights authorization requirement and the return shape (requesting user JIDs). It does not mention pagination, result limits, or behavior on a non-approval group, keeping it short of a 5.

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

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

Four short sentences with zero filler, front-loaded with the core action and followed by the precondition, safety profile, and return value. Nothing is wasted and nothing important is buried.

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

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

There is no output schema, and the description compensates by naming the returned data (requesting user JIDs), along with the auth requirement and read-only nature. Missing only edge-case behavior (empty results, pagination, non-approval groups) to be 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% ('Group JID' is documented in the schema), so the baseline is 3. The description only restates 'a group' and adds no format, JID syntax, or scoping detail beyond what the schema already 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?

States a specific verb (List), a specific resource (pending requests to join a group), and the precondition that scopes it (groups with join approval enabled). The verb contrast with the sibling whatsapp_update_group_requests is clear enough that an agent can pick correctly without opening either schema.

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

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

It gives a prerequisite ('Requires admin rights') which is genuinely useful, but never states when to choose this over the sibling whatsapp_update_group_requests (approve/reject) or what happens when the group has join approval off. Usage is implied by the verb rather than spelled out.

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

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

The readOnlyHint annotation already establishes safety, and 'Read-only' merely restates it. The description does add useful behavioral detail by disclosing the return content (groups plus count) and JID format, which compensates slightly given there is no output schema.

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

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

Three short sentences, front-loaded with the core action. The one-word 'Read-only' sentence is redundant against the annotation, a minor waste.

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

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

With no parameters and no output schema, the description carries the burden of describing returns, which it does adequately (groups and count, JID format). A small gap remains around ordering or pagination for accounts with many groups.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 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 (List) and resource (groups) with a clear scope: groups the connected number belongs to. This clearly separates it from whatsapp_get_group (single group), whatsapp_get_group_participants, and whatsapp_list_communities.

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 concrete use case -- finding group JIDs ending in @g.us -- which routes the agent here rather than to single-group lookups. It does not state explicit exclusions or name an alternative tool, but the context is clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the 'Read-only' statement is redundant. The description adds some value by listing the return fields (name, about text, picture), but it does not disclose authentication requirements, rate limits, or any other behavior beyond the annotations.

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

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

Three short sentences with zero waste, front-loading the resource and its returned fields. The information is tightly scoped to what an agent needs for a simple zero-parameter getter.

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

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

For a zero-parameter read-only profile getter with annotations covering safety, no output schema, and full schema coverage, the description is complete: it states what is returned and that the operation is read-only. Nothing essential is missing.

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

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

The tool takes zero parameters, so the baseline score is 4. The empty input schema is fully covered, and the description appropriately does not discuss parameters.

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

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

The description states a specific verb and resource: 'Get the connected number's own profile: name, about text and picture.' The word 'own' distinguishes it from sibling tools like whatsapp_get_user_profile and whatsapp_get_chat_business_profile, so an agent can identify the correct tool without opening schemas.

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

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

The phrase 'connected number's own profile' implies the usage context, but the description does not explicitly state when to use this tool versus alternatives such as whatsapp_get_user_profile. There are no exclusions or alternative-routing instructions, leaving usage 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?

The annotations already declare readOnlyHint=true and openWorldHint=true, and the description's 'Read-only' merely restates the annotation rather than adding context. It does add a rough shape of the return ('Returns the channel object'), but says nothing about failure behavior for an invalid JID or whether the JID must be a joined/subscribed channel.

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, front-loaded with the action and returned fields; only the redundant 'Read-only' sentence adds no value given the annotation.

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 one-parameter read tool with full schema coverage and annotations carrying the safety profile, the description covers what an agent needs to call it correctly; no output schema exists, so a short return hint is sufficient.

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

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

Single parameter with 100% schema coverage; the schema already documents 'id' as 'Newsletter JID'. The description's 'by JID' adds no new syntax, format, or constraint information beyond what the schema provides, 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 ('Get a channel's details') plus the fields returned (name, description, follower count), and 'by JID' implicitly separates it from whatsapp_get_newsletter_by_invite. However, it uses 'channel' while the sibling tool names use 'newsletter', which could cause a brief hesitation in mapping this tool to the newsletter family.

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 'by JID' qualifier hints at when this is the right lookup (you already have the JID, unlike whatsapp_get_newsletter_by_invite or whatsapp_list_newsletters), but no alternative is named and no explicit when-to-use or when-not-to-use guidance is 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 readOnlyHint and openWorldHint, so the safety profile is covered. The description goes beyond them by confirming the non-subscribing behavior ('without following it') and by disclosing the return payload (channel info and JID) in the absence of an output schema.

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

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

Three short sentences, front-loaded with the action and scope, then the side-effect disclaimer, then the return value. Nothing is wasted and no sentence 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 one-parameter read tool with no output schema, the description covers the action, the non-following constraint, and the returned fields — enough to invoke it correctly. It stops short of naming the sibling lookup tool an agent might confuse it with.

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 and a single parameter, the schema already defines 'code' as the newsletter invite code. The description repeats the invite-code concept but adds no format, length, or validation detail beyond the schema, 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 (look up) and resource (channel/newsletter) keyed on an invite code, which separates it from whatsapp_get_newsletter (JID-based) and whatsapp_list_newsletters. The only wrinkle is calling it a 'channel' while the tool name says newsletter, but the intent 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?

'Without following it' implies the reconnaissance use case (preview before subscribing, per whatsapp_set_newsletter_subscription), which is genuine guidance. However, it never names the alternative lookup tool or states when to prefer this over whatsapp_get_newsletter, so the routing is left implicit.

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 supply readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-derivable behavior: the logged-out-only precondition and the fact that it returns the code. It does not cover expiry or failure modes of the code, keeping it below 5.

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

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

A single dense sentence front-loads the verb and the precondition-relevant context, with zero filler. Every clause (format, purpose, alternative, precondition, return) earns its place.

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

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

With no output schema, the description compensates by stating 'Returns the code.' Combined with annotations carrying the safety profile and the explicit logged-out precondition, an agent has enough to call it correctly. Missing details like code validity window or error behavior keep it from a 5.

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 there is a single parameter, so the schema already documents 'phone' with its 7-15 digit constraint. The description only restates 'for a phone number' and adds no format or edge-case detail beyond the schema, matching the 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 (8-character pairing code for a phone number) with a concrete format detail. The phrase 'to link it without scanning a QR' distinguishes it from the sibling QR-code tools (whatsapp_get_qr_code / whatsapp_get_qr_code_image) without opening either schema.

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

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

Provides the decisive precondition 'Only works while logged out,' which is exactly the kind of when-to-use signal an agent needs. It implies the QR path as the alternative via 'without scanning a QR' but does not name the sibling tool explicitly, so it falls just short of the 5 bar.

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

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

Annotations already declare readOnlyHint=true, so the description's "Read-only" restatement carries no additional information. "Returns the settings" adds marginal transparency about the response's nature, but there is no mention of permission requirements, whether values are account-wide, or rate behavior.

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

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

Two short sentences with the scope front-loaded. Minor redundancy: "Read-only" duplicates the annotation, and "Returns the settings" is near-filler, but the description remains tight overall.

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

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

With no parameters and no output schema, the description's enumeration of returned setting categories is exactly the detail an agent needs to decide whether this tool satisfies an information need. Sufficient, though it could note the setting-value domain (e.g. everyone/contacts/nobody).

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

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

The tool takes no parameters, so the baseline is 4. The description helpfully identifies which setting categories are exposed, which is the only semantic content a zero-parameter read tool can offer.

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 ("Get the account's privacy settings") with the covered sub-settings enumerated (last seen, profile picture, about, groups, read receipts), so an agent knows exactly what this retrieves. It does not explicitly name the write counterpart whatsapp_set_privacy_setting, so differentiation is implied rather than stated.

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

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

The read-only framing implies the appropriate use case (inspecting current privacy configuration) and the sibling naming convention makes the setter the obvious alternative for changes. However, no explicit when-to-use or when-not guidance is given, leaving usage 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 readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful behavior beyond that: the logged-out precondition and the ~1 minute expiry window for each code, which materially affects call timing. It does not describe error behavior when called while logged in, keeping it short of a 5.

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

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

Four short sentences, all earning their place: purpose, precondition, expiry, and two alternatives. Purpose and precondition are front-loaded ahead of the routing hints.

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

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

For a no-parameter tool with no output schema, the description covers what the return is ('the QR string'), when it is valid, and how long it lasts. An agent has everything needed to call it correctly and interpret timing.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly notes the string return value and adds nothing spurious about nonexistent inputs.

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 the login QR code as a text string') plus the reason ('to pair a phone with this instance'). It explicitly distinguishes itself from whatsapp_get_qr_code_image and whatsapp_get_pair_code, so an agent can route without opening schemas.

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

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

Gives an explicit precondition ('Only works while logged out') and names both alternatives with the condition that selects each: image output vs pairing by phone number. Nothing 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 readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful behavioral context beyond the annotations: the precondition (must be logged out) and the short-lived nature of the credential ('each code expires within about a minute'), which affects how the caller must sequence and consume 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?

Two sentences, no filler, and the essential facts (what it returns, how it's used, the precondition, the expiry) are all front-loaded before the closing redundancy about the return 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 no-param, no-output-schema tool the description covers what is returned (a PNG), how to use it (scan from the phone), and the constraint that it only functions while logged out. Minor gap: it doesn't mention how to handle the returned binary or that a fresh call is needed after expiry.

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

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

The tool takes zero parameters and the schema is empty with 100% coverage, so there is nothing for the description to disambiguate; the baseline for a no-param tool 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+resource ('Get the login QR code') and specifies the output medium (PNG image), which distinguishes it from the sibling whatsapp_get_qr_code that presumably returns the code in text form. It does not explicitly name that sibling, so the differentiation is implicit 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?

Gives a clear precondition — 'Only works while logged out' — and the intended workflow ('to scan from WhatsApp on the phone (Linked devices)'). It does not, however, route the agent between this tool and the alternatives whatsapp_get_qr_code / whatsapp_get_pair_code when the linking flow fails or a different code format is wanted.

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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the diagnostic role and the fact it returns connection and login state, which is useful context. It does not describe return format beyond that, so not a 5.

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

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

Three short sentences, front-loaded with purpose, then behavior, then return value. Every sentence earns its place with no filler.

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

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

Given no output schema exists, the description says what is returned (connection and login state), which is sufficient for a simple diagnostic tool. It could be fuller about return values, but the core is complete for this narrow purpose.

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?

Zero parameters, so baseline is 4; the description also clarifies there is no input needed and tells what state is returned, which exceeds the baseline for a no-arg tool.

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

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

States a specific verb (check) and resource (WhatsApp session connection and login state). Clear and distinguished from all 100+ siblings, none of which report session health.

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

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

Explicitly prescribes when to call: 'Call it first when other tools fail, to tell a logged-out session from another error.' This is a clear diagnostic/alternative-use condition, not just implied context.

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

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

Annotations already declare readOnlyHint=true, so the description's 'Read-only' is largely redundant. It adds the return content ('privacy settings'), which is mild added context, but discloses nothing about scope, auth, or format beyond the safety profile.

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

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

Three short, front-loaded sentences with no filler. The purpose is stated first and every sentence carries 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 zero-param, read-only tool with annotations covering safety and no output schema, the description tells the agent what it retrieves and that it is safe. Only the exact shape of the returned settings is left unstated, which is a minor gap.

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

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

The tool takes zero parameters and schema coverage is 100%, so there is nothing for the description to compensate for. Baseline of 4 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 (who can see this number's status updates), and clarifies the return (privacy settings). It does not, however, distinguish itself from the sibling whatsapp_get_privacy_settings, which an agent could easily confuse it with.

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

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

No when-to-use guidance, no exclusions, and no mention of alternatives such as whatsapp_get_privacy_settings or whatsapp_set_privacy_setting. The agent must infer the context entirely.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds valuable context beyond annotations by noting the privacy-settings limitation ('as far as their privacy settings allow') and that it may return partial data. It restates 'Read-only' which is redundant with the annotation, but the privacy caveat is genuinely useful behavioral disclosure.

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 sentence plus two fragments ('Read-only. Returns the profile.'). The fragments are somewhat redundant with annotations and the opening sentence. The core info is front-loaded and clear, but the fragment structure feels slightly disorganized.

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 read-only tool with one parameter and no output schema, the description covers what is returned and the privacy constraint. It does not explain error cases (e.g., unknown number) or whether it requires the user to be a contact, but it is largely sufficient for correct invocation.

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

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

Schema coverage is 100% and the single 'phone' parameter is documented with an example in the schema. The description adds that the lookup is by phone number, aligning with the schema but not extending it. Baseline 3 is appropriate when the schema fully documents the parameter.

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

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

States a specific verb and resource ('Get another user's public profile') and enumerates the returned fields (name, about text, picture, business status). It is clearly distinct from whatsapp_get_my_profile and whatsapp_get_chat_business_profile because it targets another user via phone number.

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

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

The description implies the use case (fetching a stranger's public profile by phone number) but does not explicitly state when to use this versus siblings like whatsapp_get_contact or whatsapp_check_user. Usage is inferable but not guided.

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

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

Annotations already cover the safety profile (destructiveHint=false, readOnlyHint=false, idempotentHint=false). The description adds a genuinely new behavioral fact: 'Other participants see this number join.' That is real side-effect disclosure. However it omits error cases (expired code, invalid inviter) and confirmation detail, so a 3 is warranted.

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

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

Three tight sentences, front-loaded with the scope distinction and no wasted words. The mention of 'Returns a success confirmation' is slightly redundant but harmless.

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?

Covers purpose, mechanism distinction, and the visible side effect. But with no output schema, the description does little to explain the return beyond 'a success confirmation', and error/expiry behavior for a join operation is not addressed.

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 all four parameters are documented in the schema itself. The description adds only that the code/groupId/inviterId come from a received invite message, with no syntax or format detail beyond the schema. 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+resource ('Accept a group invite') and crucially distinguishes the mechanism: 'received as a direct message (not a link)'. This differentiates it from the sibling whatsapp_join_group_with_link, though it doesn't name that sibling 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 '(not a link)' parenthetical implies when to use this over the link-based sibling, and the description says to use 'the fields from that invite message'. But it never explicitly names whatsapp_join_group_with_link or states exclusions outright, leaving routing partly to inference.

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

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

Goes beyond the annotations by disclosing a real side effect visible to others ('Other participants see this number join') and the return value (joined group JID). Annotations already cover the safety profile (readOnly=false, idempotent=false), so the added social-visibility warning is meaningful extra context.

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, front-loaded with the action, then the side effect, then the alternative route, then the return value. No filler.

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

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

For a single-parameter mutation with annotations covering safety and no output schema, the description covers purpose, input format, side effect, alternative, and return value. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds the concrete link format (chat.whatsapp.com/<code>) that tells the agent the code is the trailing path segment rather than the whole URL, which the schema's terse 'Invite link code' does not.

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 (join) and resource (group) via a named input form, and the parenthetical 'chat.whatsapp.com/<code>' pins down exactly which input shape this tool takes, distinguishing it from the sibling whatsapp_join_group_with_invite.

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

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

Explicitly names the alternative workflow ('To preview the group first, use whatsapp_get_group_info_from_link'), giving a clear when-to-use-this-first context. It does not state exclusions or differentiate from whatsapp_join_group_with_invite explicitly, so it stops short of a 5.

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

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds genuinely useful behavior: other members are notified, rejoining requires a new invite (i.e., the action is effectively irreversible without outside help), and it returns a success confirmation.

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

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

Two tight sentences, zero filler, with the core action front-loaded ahead of the consequences.

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, multi-effect operation with no output schema, the description covers the key side effects (notifications, rejoin barrier) and the return shape. It only lacks guidance on when this is the right call relative to whatsapp_leave_group.

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, and schema coverage is 100% with the 'Community JID' description already in the schema (the output also lacks a description). The description adds nothing about the id field, 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 ('Leave a community and all its groups'), and the scope phrase 'and all its groups' implicitly separates it from the sibling whatsapp_leave_group, which acts on a single 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?

The description explains consequences but never says when to use this tool versus whatsapp_leave_group or when not to use it. No prerequisites or alternatives are named.

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=true and openWorldHint=true, so safety is covered structurally. The description adds genuinely new behavioral context: other participants get notified, rejoining requires a fresh invite, and an admin role is auto-reassigned if this number is the sole admin. It stops short of explaining failure modes or what happens if the id is invalid.

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, zero filler, with the core action front-loaded and the side effects and edge case following in order of importance.

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 closes the loop by stating a success confirmation is returned, and it covers the side effects and admin edge case an agent should anticipate for a destructive group operation.

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

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

The single id parameter is fully documented in the schema as 'Group JID' (100% coverage), so the schema carries the semantics. The description adds nothing about the parameter beyond what is already structured; 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 (leave) and resource (group) immediately, which cleanly separates it from the nearby whatsapp_leave_community and the group-management siblings like update_group_participants.

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 action is unambiguous, but the description never states when to use this versus alternatives (e.g. leave_community) or any precondition on the id. The note about needing a new invite to rejoin is a consequence, not explicit routing guidance.

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

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

Annotations already declare readOnly=false, destructive=false, idempotent=true, and openWorld=true. The description goes beyond them by adding an authorization requirement, a significant side effect (group members become community members), and the return shape (success confirmation). It stops short of covering failure modes or reversibility.

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?

Four short sentences, each front-loaded with essential information: action, prerequisite, side effect, return. 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?

For a mutation tool with full annotation coverage, a two-parameter schema, and no output schema, the description provides the key context: authorization needs, member migration, and a simple return confirmation. Minor gaps remain around failure behavior or reversibility, but an agent has enough to call it correctly.

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

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

Schema coverage is 100%, so both parameters are fully documented as Community JID and Group JID. The description adds no extra syntax, format, or constraint details for either parameter beyond what the schema already provides.

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

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

The description uses a specific verb+resource ('Attach an existing group to a community') and clearly distinguishes itself from sibling tools like unlink_community_group and create_community_group. An agent can identify the exact operation without opening the schema.

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

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

It states a clear prerequisite ('Requires admin rights in both') and implies the context of attaching an existing group. It does not, however, explicitly name alternative tools or when-not-to-use conditions, so it falls short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful return context ('returns the communities and their JIDs'), but it does not discuss pagination, authentication, or ordering. Repeating 'Read-only' adds little beyond the annotation.

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

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

The description is three short sentences with no wasted words. The core action is front-loaded, and the read-only qualifier and return summary follow 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 zero-parameter read-only list tool with annotation coverage and no output schema, the description is nearly complete: it states what is listed and what is returned. It could mention whether results are paginated or include additional metadata, but the essential information for calling it correctly is present.

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

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

The tool has zero parameters, so the schema provides no parameter semantics to explain. The baseline for a no-parameter tool is 4, and the description does not need to compensate for any parameter documentation gap.

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

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

The description states a specific verb ('List') and resource ('communities'), scoped to those the connected number belongs to. It is distinguishable from single-community tools like whatsapp_get_community, but it does not explicitly name any sibling alternative or contrast behavior.

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

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

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as whatsapp_get_community for detailed community data. Usage is only implied by the tool name and the phrase 'belongs to'.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds the return shape ('the channels and their JIDs'), which matters because there is no output schema — useful context beyond the structured fields.

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, zero waste, and the scoping constraint and read-only nature are front-loaded before the return note.

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

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

For a zero-parameter read tool with annotations covering safety and the description covering the return payload, nothing essential is missing. Slightly short of 5 only because no guidance on combining it with the per-channel getters is offered.

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?

Zero parameters, so per the rubric the baseline is 4. There is nothing parameter-related the description needs to explain.

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

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

States a specific verb (list) and resource (channels/newsletters), and explicitly disambiguates the synonym 'channels (newsletters)'. An agent can distinguish it from whatsapp_get_newsletter and whatsapp_list_communities without opening a schema.

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

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

The scope 'this number follows or owns' implies when it applies, but no alternatives are named (e.g., get_newsletter for a single channel) and no prerequisites or exclusions are given. Usage is implied rather than explicit.

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

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

The annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds meaningful context beyond that: the blast radius on all other tools and the recovery path via QR/pair code. It omits auth/prerequisite requirements, keeping it out of 5 territory.

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, front-loaded with the action, then the consequence, then the return value. No filler or restatement of the name or annotations.

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 usefully states the return value ('a success confirmation') and discloses the post-logout state and recovery route. For a zero-param destructive terminal action this is nearly complete; only preconditions/permissions are unaddressed.

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?

Zero parameters, so the baseline is 4 per the rubric; there is no parameter surface for the description to explain or omit.

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

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

States a specific verb+resource ('Log this instance out of WhatsApp and unlink it from the phone') with unambiguous scope. No sibling tool covers logout, so there is nothing to disambiguate against; it falls just short of a 5 only because it names no alternative or contrast case.

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 describes the operational consequence ('Every other tool stops working until the number is paired again') and implicitly points at the re-pairing tools (get_qr_code, get_pair_code), but never explicitly says when to invoke this tool or what must precede it. 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=false, idempotentHint=true and openWorldHint=true, so the safety profile is covered externally. The description adds a useful return note ('Returns a success confirmation') and the state-change semantics of read/unread, but says nothing about account/auth requirements for 'this account' or any rate limits.

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

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

Three short sentences, each earning its place: the action, the disambiguation from the sibling, and the return value. Front-loaded with the core purpose and no filler.

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

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

For a two-parameter mutation with full schema coverage and no output schema, the description covers purpose, the sibling boundary, and the success return. Only minor gaps remain (no mention that an unread marking may re-trigger unread counts, or any auth context for 'this account').

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

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

Schema description coverage is 100% and both parameters are documented there (read = true/false, chatId = Chat JID), so the schema does the heavy lifting. The description only reinforces that the boolean toggles chat-level read state; it adds no format or validation detail beyond the schema.

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

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

States a concrete verb+resource plus scope: 'Mark a whole chat as read or unread on this account.' The word 'whole chat' plus the explicit contrast with whatsapp_mark_message_read makes the boundary between the two tools 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?

Names the alternative tool (whatsapp_mark_message_read) and the condition that selects it ('for one message'), which is exactly the kind of routing an agent needs among ~90 siblings. It stops short of stating prerequisites or edge cases (e.g. group vs. individual chats), so it is clear context rather than full when/when-not guidance.

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

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

Annotations already cover the safety profile (readOnly=false, idempotent=true, destructive=false). The description adds the visible effect ('blue ticks') and a privacy caveat, plus mention of a success confirmation—useful context for a mutation. It does not detail side effects like rate limits or idempotency mechanics, but that is minor given annotations.

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

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

Two sentences, front-loaded with the primary action and immediately followed by the alternative. Every sentence earns its place with no filler.

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

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

For a four-param mutation with full schema coverage and annotations, the description covers purpose, alternative, effect, and return. No output schema exists, so mentioning the success confirmation suffices. It is largely complete, though idempotency is only in 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%, so the schema documents all four parameters, including an enum for receiptType. The description adds no parameter syntax or format details beyond what the schema provides, making 3 the 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 ('Send a read receipt for a message') and distinguishes from the sibling 'whatsapp_mark_chat_as_read' by name. An agent can tell exactly what this does versus the whole-chat variant.

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

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

Explicitly routes the agent to 'whatsapp_mark_chat_as_read' for marking a whole chat, providing a clear when-to-use alternative. No further exclusions are needed.

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 carry the safety profile (idempotent, non-destructive, open-world). The description adds genuinely useful context beyond them: 'Only affects this account; the other side is not told' discloses the local-only scope, and the return confirmation is noted even though no output schema exists.

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

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

Three short, front-loaded sentences with no filler. Each sentence carries distinct information: action, scope/side-effect, and return behavior.

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 2-parameter tool with full schema coverage and rich annotations, the description covers purpose, side effects and return adequately. The only gap is lack of sibling differentiation, which is minor given the clear 'chat' resource.

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 an enumerated duration, so the schema does the heavy lifting. The description's phrase 'or unmute it' marginally clarifies that the 'off' enum value means unmute, but otherwise adds little beyond the schema.

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

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

States a specific verb (mute/unmute) and resource (a chat's notifications), and the dual nature (mute or unmute) is clear. It does not explicitly differentiate itself from the sibling whatsapp_mute_newsletter, though the 'chat' resource 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?

Usage is implied by the duration enum semantics ('off' = unmute) rather than stated. There is no explicit when-to-use guidance, no mention of prerequisites, and no routing to sibling tools like archive_chat or mute_newsletter.

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 the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the mutation and idempotency characteristics are covered. The description adds useful return context ('Returns a success confirmation'), which is valuable since no output schema exists, but says nothing about permission requirements or side effects.

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

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

Two short sentences with zero padding; the action is front-loaded and the return note follows. Appropriately sized for a simple toggle 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 2-parameter toggle with no output schema, the description covers purpose and return behavior adequately. It omits disambiguation from whatsapp_mute_chat and what a 'channel' JID refers to, leaving a small gap an agent might need.

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 (id=Newsletter JID, mute=boolean) are fully documented in the schema. The description adds no additional parameter semantics, 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 pair (mute/unmute) and resource (a channel's notifications), and scopes it to 'this account'. The resource term 'channel' rather than 'newsletter' is slightly ambiguous against siblings like whatsapp_mute_chat, but the intended target is still clear from the tool name.

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 the closely related sibling whatsapp_mute_chat, and no exclusions or prerequisites. 'on this account' is a minor scope note but does not tell the agent when to pick this over alternatives.

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

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

Annotations already declare mutation (readOnlyHint=false), idempotence, and non-destructiveness, so the bar is lower. The description adds useful behavioral context beyond annotations: it scopes the effect to 'this account' and states that it 'Returns a success confirmation,' which tells the agent what to expect from the call. It does not cover permissions or rate limits, but those are minor for this simple 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?

Three short sentences with zero waste. The primary action is front-loaded, the scope and alternative follow immediately, and the return behavior closes 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 toggle with rich annotations and no output schema, the description is complete. It covers the action, the account scope, the key alternative tool, and the response shape, leaving no meaningful gap for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters ('Chat JID' and 'Pin or unpin'). The description adds no syntax, format, or edge-case detail beyond what is already in 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 and resource ('pin a chat to the top of the chat list, or unpin it') and explicitly distinguishes itself from the sibling whatsapp_pin_message by naming it and explaining the difference. An agent can tell exactly what this tool does and what it does not.

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

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

Provides an explicit alternative for the most likely confusion: 'To pin a message inside a chat, use whatsapp_pin_message.' It also clarifies the scope of the effect ('Only affects this account'), so the agent knows when this tool is appropriate versus its message-level sibling.

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

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

Adds valuable context beyond annotations: everyone in the chat sees the pin (social/visibility behavior), and supports time-limited pinning. The success confirmation is stated. Annotations cover the safety profile (idempotent, non-destructive, open world), so remaining gaps are minor.

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

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

Three tight sentences: action, visibility note, sibling routing, and return value. Front-loaded with the core action; zero waste.

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-param mutation tool with full schema coverage and annotations covering safety, the description is nearly complete. It could explain unpin semantics or default pin duration, but nothing critical to correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters (including pinned flag and pinExpiration format). The description only hints at 'optionally for a limited time,' adding little beyond what the schema provides. 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 (pin/unpin), resource (message in a chat), and disambiguates from the near-identically-named sibling whatsapp_pin_chat by naming it directly. An agent can immediately distinguish 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?

Explicitly routes the agent: 'To pin a whole chat in the list, use whatsapp_pin_chat.' This is exactly the alternative-selection guidance needed given the confusingly similar sibling 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 cover the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), so 'Not idempotent' is largely redundant. However, the description adds genuinely new behavioral context: the 24-hour visibility window to allowed contacts and the fact that the status message ID is returned, which matters since there is no output schema.

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

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

A single tight sentence, front-loaded with the action and resource, with the source variants, caption, audience, lifetime, idempotency and return value packed in without waste.

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 usefully names the returned status message ID, and it covers visibility, lifetime, and the two input modes. It does not clarify that at least one of url/data must be supplied despite zero required parameters, which leaves a minor gap.

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

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

Schema description coverage is 100%, so all four parameters are already documented, making 3 the baseline. The description's 'from base64 data or a public URL' adds a small amount of disambiguation between the url and data parameters but nothing about mimeType or caption 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 ('Post an image status (story)'), names both accepted input sources, and specifies the caption and audience/expiry. It is clearly distinguishable from siblings like whatsapp_post_text_status and whatsapp_post_video_status without opening any schema.

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

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

The description implies when to use it (posting an image story) and contrasts the two input sources, but never explicitly routes the agent against alternatives such as post_text_status, post_video_status, or send_image. No when-not guidance is provided, so usage is only implied.

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 idempotentHint=false, so 'Not idempotent' largely restates structured data, but the description adds real value beyond it: the 24-hour ephemeral lifetime, the visibility scope tied to status privacy settings, and the returned status message ID. These are behavioral facts the annotations cannot convey.

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

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

Two tight sentences, front-loaded with the action and scope; the cross-reference to whatsapp_delete_status is placed last where it belongs. No filler.

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

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

Compensates for the absent output schema by naming the return value, and covers lifetime and audience scope. Only minor gaps remain, such as any auth/session requirement for posting.

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 ('text') with 100% schema description coverage, and the description adds no formatting, length, or encoding guidance beyond the schema. Under the high-coverage baseline, the schema carries this dimension.

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 (post a text status/story) with enough scoping detail to separate it from the sibling media variants whatsapp_post_image_status and whatsapp_post_video_status. An agent can route on the name plus the 'text' qualifier without opening the schema.

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

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

Gives clear context (status visible to privacy-permitted contacts, expires in 24 hours) and implies the intended use case, but never explicitly states when to prefer this over the image/video status siblings or any prerequisite such as an active session.

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, idempotent=false, destructive=false and openWorld=true, and the description reinforces non-idempotency plus adds genuinely new behavior: the 24-hour expiry, audience scope (allowed contacts), and the return value (status message ID). That is useful context beyond the annotations, though it doesn't cover failure modes or size/format limits for large base64 payloads.

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 action and media type, followed by the source, caption, visibility, idempotency and return-value facts. No filler.

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

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

For a 4-parameter tool with no output schema and 0 required parameters, the description supplies the essentials: source options, caption, visibility, non-idempotency, and the returned ID. It stops short of clarifying the url/data exclusivity or any media constraints, which leaves a small gap for an agent assembling the 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 description coverage is 100%, so the baseline is 3. The description adds the important nuance that url and data are alternative sources for the video and that caption is optional, but does not resolve whether the two source parameters are mutually exclusive or which wins if both are supplied.

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

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

States a specific verb+resource ('Post a video status (story)') and immediately distinguishes itself from the text/image status siblings by naming the media type. It also clarifies accepted sources (base64 data or public URL) and the optional caption, so an agent knows exactly what this tool does.

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

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

Provides clear context for use: visibility is restricted to allowed contacts and lasts 24 hours, matching the ephemeral-status semantics of the sibling post_text_status/post_image_status tools. It does not explicitly say 'use this instead of post_text_status when the payload is a video,' but the media-type framing makes the routing obvious.

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 this as a non-readOnly, idempotent, non-destructive write. The description adds genuinely supplementary behavior: the caller visibly sees the call declined and the operation fails outside the ringing window. It also notes the success-confirmation return.

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

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

Three tight sentences: action first, then parameter origin, then the timing constraint and return. Every sentence earns its place with zero filler.

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

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

For a two-parameter mutation tool with no output schema, the description covers the action, parameter origin, timing precondition, and return shape. It gives enough for correct invocation, though it could note the idempotency guarantee already implied by 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 the baseline is 3, but the description adds sourcing value by tying both IDs to the call_offer event, helping the agent locate the correct values rather than treating them as arbitrary strings.

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

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

States a specific verb+resource ('Reject an incoming WhatsApp call') with scope and no ambiguity. No sibling tool overlaps with call rejection, so an agent can select it unambiguously from the list.

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 for use ('using the callId and callerId from the call_offer event') and a hard precondition ('Only works while the call is still ringing'). It does not name an explicit alternative (e.g., answering), but the usage window is well-defined.

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

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

Discloses behavior the annotations cannot convey: the call does NOT return messages, the actual messages arrive asynchronously as history-sync events, and they only arrive 'if the phone provides them'. This is exactly the context an agent needs to avoid mis-handling the acknowledgement as a result set.

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, front-loaded with the action, then the async caveat, then the return shape. Nothing is padded and the most surprising fact (no messages returned) is stated early.

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

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

There is no output schema, so the description carries the return-value burden — and it does so explicitly ('Returns an acknowledgement only'), while also explaining the real delivery channel. An agent has everything needed to call it and interpret the response.

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 count, chatId, lastMessageId and lastMessageSenderId. The description adds only the 'starting before' framing for the anchor, which is marginal value over structured data. 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 ('Ask WhatsApp for older messages of a chat') plus the exact anchor point ('starting before a given message'). No sibling tool performs history backfill, so it is unambiguously distinguishable from the get/send/mutate siblings.

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

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

The context for use is clear: recover older messages of a known chat when you have a last-known message reference. It does not name any alternative sibling or state exclusions, but no sibling competes for this job, so the gap is minor.

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 implies non-idempotent behavior: each call creates a new link and returns it, so repeated calls produce different results. This directly contradicts the annotation idempotentHint=true. Although it adds useful context (old link stops working immediately, admin required, returns new link), the contradiction forces a 1 per the rules.

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?

Four short sentences, each front-loaded with essential information: action, immediate consequence, prerequisite, and return value. No waste.

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 (one parameter, no output schema) and existing annotations, the description covers the key points an agent needs: purpose, destructive effect, auth requirement, and return value.

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