Server Quality Checklist

Tool Scores

• send_fileC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It mentions sending files but does not describe side effects, required permissions, error conditions, or how the 'auto' kind determines the file type. This leaves important behavioral traits undisclosed.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with no filler. The main action and supported file types are front-loaded, making it easy to scan and understand.

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

  Completeness2/5

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

  Given no annotations, no output schema, and a 50% schema description coverage, the description leaves gaps around parameter semantics, usage conditions, and behavioral expectations. It is adequate for identifying the tool's basic purpose but not for fully supporting correct invocation.

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

  Parameters3/5

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

  Schema coverage is 50%, documenting only 'to' and 'path'. The description enumerates file types that map to the 'kind' enum, adding some meaning, but it does not clarify the 'caption' parameter or the behavior of the 'auto' default. The description partially compensates for the undocumented parameters.

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

  Purpose4/5

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

  The description states a specific verb ('Send') and a clear resource: image, video, audio, voice note, or document from a local path. This clearly differentiates it from text-messaging tools like send_message, though it does not explicitly contrast it with other file-related tools.

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

  Usage Guidelines2/5

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

  No guidance is provided about when to use this tool versus alternatives such as send_message or broadcast_message. The only contextual clue is 'from a local path,' which implies local file sending, but there are no explicit conditions, exclusions, or alternative references.

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

• download_mediaB
  3.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the side effect of saving media to disk and notes that images are returned inline, which is useful. However, it omits error behavior, handling of non-image media, file naming/overwrite behavior, and whether the operation can be safely repeated.

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

  Conciseness5/5

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

  Two short sentences with no filler. The primary action is front-loaded in the first sentence, and the second sentence adds a behavioral detail about inline images. Every word earns its place.

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

  Completeness3/5

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

  For a simple two-parameter download tool, the description covers the core action and hints at response behavior. However, with no output schema and no annotations, it leaves gaps around return format, non-image media behavior, file paths, and edge cases. It is adequate but not fully complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, as both 'chat' and 'message_id' have meaningful descriptions. The description itself adds no parameter-level detail beyond what the schema already states, so the baseline of 3 applies.

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

  Purpose4/5

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

  The description states a specific verb and resource: 'Download the media of a stored message to disk.' It is distinct from sibling tools like send_file or get_messages, though it does not explicitly name a sibling for differentiation. The title 'Download an attachment' reinforces the purpose, so the tool's goal is clear.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no explicit context such as 'use when you need an attachment saved to disk.' The only implied usage is via the schema hint that message_id comes from get_messages / search_messages, but the description itself gives no selection guidance.

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

• list_chatsB
  3.3/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the behavioral burden. It does disclose that the result is a list of recent chats with unread counts and a last-message preview, which implies a read-only overview operation. However, it does not clarify ordering, pagination behavior, whether archived chats are excluded by default beyond the schema default, or any other side-effect-free guarantees.

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

  Conciseness5/5

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

  The description is a single front-loaded sentence with no wasted words. It immediately identifies what the tool lists and what the returned data includes. Every word contributes to the agent's understanding.

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

  Completeness3/5

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

  The schema fully documents parameters, but there is no output schema and no annotations, leaving the description as the only source for return-shape and behavior details. It gives a high-level preview of return contents but not the full structure, sort order, or default exclusion semantics. For a simple listing tool this is adequate but not complete.

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

  Parameters3/5

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

  Schema documentation covers 100% of the parameters, so the baseline is 3. The description adds no parameter-specific meaning beyond mentioning unread counts and message previews, which loosely relates to unread_only and the returned fields. It does not enrich or contradict the schema, so it stays at baseline.

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

  Purpose4/5

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

  The description uses a clear verb and resource pair ('Recent WhatsApp chats') and names what the tool returns (unread counts and last message preview). It is easy to distinguish from sibling tools like get_messages or list_communities even though no sibling is explicitly named. It loses a point because it does not actively contrast itself with related tools.

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

  Usage Guidelines2/5

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

  There is no guidance about when to use this tool instead of alternatives such as get_messages, search_messages, or search_contacts. The description implies a top-level overview use case, but it never states exclusions or conditions. The 5 filter parameters suggest flexibility, but no scenario guidance is given.

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

• whatsapp_statusB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description must disclose behavioral traits itself. It implies a read-only operation but never explicitly states that it makes no changes, requires authentication, or could fail when disconnected. The agent is left uncertain about side effects and operational context.

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

  Conciseness5/5

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

  A single, dense sentence covers all key information without wasted words. The primary concept (connection state) appears first, followed by supporting details. No redundant phrasing or filler.

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

  Completeness4/5

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

  For a zero-parameter status tool with no output schema, the description adequately conveys the scope of returned data. It lists the categories an agent would care about, though it could mention that the output is a status object or that it reflects local storage. Minor gaps remain, but the tool is simple enough that this is sufficient.

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

  Parameters4/5

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

  The tool accepts zero parameters, so the baseline is 4. There is nothing for the description to add about parameter meanings; the description appropriately focuses on what the tool returns, which is the relevant aspect for an agent.

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

  Purpose4/5

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

  The description clearly specifies what information is returned: connection state, linked number, and local counts of chats/contacts/messages. It distinguishes the tool from sibling actions like send_message or list_chats by describing it as a status/info endpoint, though it lacks an explicit verb like 'get' or 'return'.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus its siblings. It does not mention that it is suitable for checking account connectivity before sending messages or that it can be used to see storage counts. No alternatives or exclusion conditions are stated.

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

• get_group_infoB
  3.4/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the burden of behavioral disclosure. It states what information is returned but does not mention side-effect-free behavior, error cases, or any access requirements. The description is not misleading, but it adds only minimal behavioral context.

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

  Conciseness5/5

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

  A single, compact sentence that front-loads the core output contents. Every word adds value, and there is no redundant or filler language.

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

  Completeness4/5

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

  For a simple single-parameter tool with no output schema, the description adequately lists the return data (subject, description, participant list). It is mostly complete, though it would benefit from noting failure behavior or a return format, but given the low complexity this is not a critical gap.

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

  Parameters3/5

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

  The only parameter, 'group', is already fully described in the schema as 'Group name or jid' (100% coverage). The description adds no additional meaning about the parameter, so the baseline score of 3 applies.

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

  Purpose4/5

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

  The description clearly names the resource (WhatsApp group) and the specific payload (subject, description, participant list). It distinguishes itself from siblings like update_group or manage_group_participants by implying a read-only information lookup, though it relies on the tool name for the verb rather than stating it explicitly.

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

  Usage Guidelines2/5

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

  No guidance is provided about when to use this tool versus alternatives. It does not mention related tools such as refresh_groups or list_chats, nor does it give any exclusions or prerequisites.

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

• list_communitiesB
  3.4/5.0
  Behavior3/5

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

  No annotations exist, so the description is the sole disclosure. It does reveal account-scoping and the nested inclusion of linked groups, but says nothing about read-only guarantees, pagination, ordering, or response shape.

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

  Conciseness4/5

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

  One concise fragment without filler. It front-loads the core content, though a proper verb would make it a full sentence.

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

  Completeness4/5

  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 explains what data will be returned (communities plus linked groups) and its scope. The lack of an output schema is mitigated by this high-level return description, though details like field names are absent.

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

  Parameters4/5

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

  Tool has zero parameters, so the schema already covers everything; the baseline for no parameters is 4. No parameter explanation is needed.

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

  Purpose4/5

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

  States the resource ('communities') and scope ('this account belongs to'), plus the included nested data ('groups linked inside each one'). The verb is implied from the title, so the purpose is clear; it doesn't explicitly contrast with sibling tools like list_chats.

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

  Usage Guidelines2/5

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

  No sentence tells the agent when to choose this over siblings such as list_chats or search_contacts. Use context is only implicit from the resource type, with no exclusions or alternative guidance.

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

• search_contactsB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavior on its own. It conveys a read-style search operation but does not mention that it is non-mutating, what matching rules apply, whether results include groups only or also users, or how limit affects results.

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

  Conciseness5/5

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

  A single, front-loaded sentence communicates the core operation and search criteria with no filler or repetition. Every word earns its place.

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

  Completeness3/5

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

  For a simple read-only search with two parameters, the description reaches a minimum viable level: an agent can identify the purpose and construct a query. However, with no output schema and no mention of result shape, matching behavior, or limit semantics, it leaves several non-obvious details to inference.

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

  Parameters2/5

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

  The description adds little beyond the schema for the query parameter and does not explain the limit parameter at all. With schema coverage at 50%, one parameter's semantics are only inferable from its name and numeric constraints.

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

  Purpose5/5

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

  The description uses a specific verb ('Find') and names the resource clearly: people or groups, searched by name or phone number. This distinguishes it from siblings like search_messages and other contact-adjacent tools.

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

  Usage Guidelines3/5

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

  The description implies the tool is for looking up contacts or groups by name or phone, but it does not explicitly state when to prefer it over alternatives such as search_messages or list_chats. There is no when-not guidance.

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

• update_groupB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It does disclose that this is a mutating operation and that admin privileges are required, and it names the settings that can be changed. However, it does not describe side effects, whether updates are partial or full replacements, or what the response will contain.

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

  Conciseness5/5

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

  The description is a single concise sentence that immediately lists the main operations and closes with the admin requirement. Every phrase contributes meaning, and there is no redundant or vague wording.

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

  Completeness3/5

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

  For a 7-parameter mutation tool with no annotations and no output schema, the description covers the core intent and the admin prerequisite, but it omits important invocation details such as whether unspecified settings are left unchanged, whether at least one setting must be provided, and what happens on success or failure. It is adequate but not fully complete.

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

  Parameters4/5

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

  Schema description coverage is only 43%, so the description needs to compensate. It does this well by paraphrasing several undocumented parameters: 'post' maps to who_can_message, 'edit info' to who_can_edit_info, 'add members' to who_can_add_members, and 'join' to join_approval_required. It adds semantic value for four parameters beyond the schema.

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

  Purpose4/5

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

  The description uses specific verbs (rename, change) and identifies the resource as group settings, listing concrete capabilities: description, posting permissions, editing info, adding members, and join approval. It is clear and distinct from the sibling tools in practice, though it does not explicitly point to an alternative.

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

  Usage Guidelines2/5

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

  The only usage guidance is 'Requires admin,' which is a prerequisite rather than a when-to-use/exclusion statement. It does not explain when to prefer this over siblings like manage_group_participants or link_group_to_community, or what scenarios are outside its scope.

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

• send_messageA
  3.6/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral burden. It adds a consent requirement ('Confirm the recipient') and optional reply behavior, but does not mention immediate delivery, inability to unsend, or whether a sent confirmation or error is returned.

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

  Conciseness5/5

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

  Three short sentences with no filler; the core action is first, the safety guard second, and the optional behavior third. Every sentence earns its place.

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

  Completeness4/5

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

  For a low-complexity send operation, the essential call information is covered: what to send, the confirmation prerequisite, and optional quoting. With no output schema, it could briefly state expected return feedback such as message id or status, but that is not critical for invoking the tool.

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

  Parameters3/5

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

  The input schema already describes all three parameters well, including acceptable values for 'to' and the meaning of reply_to. The description adds only limited new information by labeling reply_to as optional and confirming the 'by id' semantics.

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

  Purpose4/5

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

  States a specific action ('Send a text message') on a distinct resource, and the optional quote behavior differentiates it from file transfer. However, it does not explicitly distinguish send_message from broadcast_message, both of which may send text.

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

  Usage Guidelines3/5

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

  Explicitly instructs the agent to confirm the recipient with the user before calling, which is a clear when-to-use guard. It does not name alternatives like send_file or broadcast_message, so the agent must infer when this tool is preferred.

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

• broadcast_statusA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of explaining behavior. It discloses the dual nature of the tool—querying status and canceling running broadcasts—and notes cancellation applies only while running. However, it does not elaborate on cancellation side effects, output shape, or error behavior, leaving some transparency gaps.

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

  Conciseness5/5

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

  Two short sentences, each earning its place. The primary purpose is front-loaded, and the cancellation capability is stated without any filler or redundancy.

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

  Completeness3/5

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

  The description names what the tool reports and its cancel feature, and the schema covers both parameters. However, since there is no output schema, more detail about the expected response shape, such as fields included in per-recipient results or job state, would make the tool easier to invoke and interpret correctly.

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

  Parameters3/5

  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 useful domain context by linking to broadcast_message and clarifying that cancellation applies to running broadcasts, but it does not materially improve on the schema's already clear parameter descriptions for job_id and cancel.

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

  Purpose5/5

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

  The description clearly identifies the tool as reporting progress and per-recipient results for broadcasts started with broadcast_message, and also mentions its cancellation capability. This distinguishes it from related sibling tools like broadcast_message and whatsapp_status.

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

  Usage Guidelines4/5

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

  The description gives clear context: use this tool after starting a broadcast with broadcast_message to monitor or cancel it. It does not explicitly list when not to use it or name alternative status tools, but the broadcast-specific framing makes the intended usage evident.

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

• get_messagesA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It communicates read-only intent, ordering, and pagination behavior, but does not disclose whether reading marks messages as read, what the response shape is, or potential side effects. This is a meaningful gap for a no-annotation tool.

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

  Conciseness5/5

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

  Two short sentences with no filler. The core action and ordering are front-loaded, and the pagination guidance is compact and actionable. Every sentence earns its place.

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

  Completeness3/5

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

  The tool has a simple interface, but because there is no output schema and no annotations, the description should explain more about the return value and limits. The current description is adequate for basic selection but leaves uncertainty about message format, default/limit behavior, and any read side effects.

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

  Parameters3/5

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

  Schema description coverage is 67%; the description adds useful paging context for `before`, but offers no extra semantics for `chat` or `limit`. Since `limit` lacks a schema description, the description could have compensated but does not.

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

  Purpose5/5

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

  The description uses a specific verb ('Read') and resource ('messages'), and narrows scope to 'one chat' with ordering 'newest last'. This clearly distinguishes the tool from siblings like search_messages, send_message, and list_chats.

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

  Usage Guidelines4/5

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

  It conveys clear usage context: retrieve messages from a single chat in chronological order, and page further back using the `before` parameter. It does not explicitly mention alternatives or when-not-to-use, but the context is strong enough for an agent to select it appropriately.

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

• refresh_groupsA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It does reveal that the tool re-fetches all groups and fills only missing group names, which is useful. Still, it says nothing about permissions, possible failures, rate limits, or whether any existing data is overwritten.

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

  Conciseness5/5

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

  The description is a single, tightly written sentence that leads with the core action and then gives the specific benefit. Every word contributes value, and there is no redundant filler.

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

  Completeness3/5

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

  The tool is simple with no parameters, so invocation is straightforward. However, with no output schema and no annotations, the description does not clarify what the caller gets back or what side effects beyond filling missing names may occur, leaving some operational uncertainty.

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

  Parameters4/5

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

  The input schema has zero parameters, so there are no parameter semantics to document. The description still adds context about what data is affected, which is sufficient given the empty schema.

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

  Purpose5/5

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

  The description states a specific action ('re-fetch') and resource ('every group the account belongs to'), and adds the outcome ('filling in missing group names'). This clearly separates it from single-group tools like get_group_info.

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

  Usage Guidelines3/5

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

  The intended use is implied: refresh the account's group list when group names may be missing or stale. However, it does not explicitly state when to choose this over alternatives like get_group_info, nor does it mention any prerequisites or exclusion cases.

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

• search_messagesA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full transparency burden. It conveys that the operation is a non-destructive full-text search and that it operates globally or per chat, but it does not disclose the result format, ordering, pagination behavior, or any limitations beyond the schema's limit field.

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

  Conciseness5/5

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

  A single, front-loaded sentence with no filler. It states the core action and the key scoping distinction without redundantly repeating the tool name or title.

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

  Completeness3/5

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

  For a relatively simple search tool, the description is usable but not fully complete. It does not mention what the returned messages look like, whether results are ordered by relevance or date, or how it relates to get_messages as an alternative. The absence of an output schema makes some of this information valuable.

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

  Parameters3/5

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

  Schema coverage is 67%, covering query and chat. The description adds meaning by clarifying that chat restricts the search 'to one chat' versus all chats. The limit parameter is not described in prose, but its default/min/max constraints in the schema already communicate its numeric semantics.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Full-text search across stored messages.' It also clarifies the scope ('in every chat, or in one chat'), which distinguishes it from a plain message-listing tool and positions it clearly among siblings.

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

  Usage Guidelines4/5

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

  The description clearly indicates when to use the tool: when full-text search over stored messages is needed, with an optional single-chat restriction. It lacks explicit exclusions or named alternatives like get_messages, but the context is strong enough for an agent to infer the correct use.

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

• create_communityA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It reveals a key non-obvious constraint: members are not added directly to a community; they join via its groups. However, it does not mention permissions, what happens to groups passed in link_groups, or what the operation returns, leaving meaningful gaps.

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

  Conciseness5/5

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

  The description is three sentences with no filler: it defines the resource, clarifies the membership model, and directs the next action. Every sentence contributes value and the key information is front-loaded.

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

  Completeness4/5

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

  For a relatively simple creation tool with no annotations and no output schema, the description gives solid conceptual grounding and workflow guidance. It does not mention operational prerequisites or the full effects of link_groups, but for an agent familiar with common API patterns this is mostly complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all three parameters. The description adds useful context about communities and groups but does not meaningfully elaborate on parameter semantics beyond what the schema provides, 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.

  Purpose5/5

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

  The description states a specific action and resource: creating a WhatsApp community. It defines what a community is (an umbrella that holds groups with an announcement channel) and distinguishes itself from sibling tools by explicitly pointing to link_group_to_community and create_group for adding groups.

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

  Usage Guidelines4/5

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

  The description explains that members join through groups, not directly, and gives explicit next-step guidance: use link_group_to_community or create_group(community=...) after creating. It could be more explicit about when not to create a community, but the conceptual framing makes the intended workflow clear.

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

• create_groupA
  4/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the behavioral burden. It adds a useful behavioral requirement—confirming the group name and members with the user—and the community option. However, it does not disclose side effects, return values, permission requirements, or what happens if a participant cannot be added.

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

  Conciseness5/5

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

  Two sentences front-load the core purpose and then add the most important usage instruction—confirmation—plus the relevant community optionality. There is no filler or redundant restating of the schema.

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

  Completeness4/5

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

  For a creation tool with 5 parameters, 2 required, and no output schema, the description plus fully covered schema is enough to invoke correctly: what to create, what to confirm with the user, and the optional community parameter. A note about the response or side effects would improve completeness, but it is not essential for correct selection and invocation.

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

  Parameters3/5

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

  The schema already documents all five parameters with descriptions, giving 100% coverage, so the baseline is 3. The description's 'initial set of people' and 'inside a community' loosely map to participants and community, but it adds no format or constraint details beyond the schema.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'Create a WhatsApp group with an initial set of people.' It clarifies this is about initial creation rather than later updates, distinguishing it from siblings like update_group and manage_group_participants. The optional community placement also separates it from link_group_to_community.

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

  Usage Guidelines4/5

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

  The description gives clear pre-invocation guidance: confirm the name and member list with the user first. It also notes the optional community context. It does not explicitly name alternatives or state when not to use this tool, but the creation scenario is clear enough for an agent to route correctly.

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

• group_invite_linkA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly warns about the destructive revoke action ('revoke the old one') and states the admin requirement. However, it does not mention behavior like whether a link is created if none exists, or the exact response format, so it is not fully transparent.

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

  Conciseness5/5

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

  The description is two concise sentences with no redundant phrasing. It front-loads the primary purpose, then states the optional revoke behavior and the admin requirement. Every sentence adds meaningful information.

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

  Completeness4/5

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

  For a simple two-parameter tool with no output schema, the description covers the core operation, the optional destructive mode, and a key prerequisite (admin). It does not explicitly state what the tool returns, but 'Get the join link' strongly implies the output. Minor gaps remain, such as behavior when no link exists, but the description is adequate for a low-complexity tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the parameters 'group' and 'revoke' are already well documented in the schema. The description adds no additional parameter-level meaning beyond what the schema provides. The baseline of 3 applies because the schema carries the parameter documentation burden.

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

  Purpose5/5

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

  The description clearly states the specific action: 'Get the join link for a group, or revoke the old one and issue a fresh link.' This distinguishes the tool from all siblings by focusing on the invite link resource, which no other sibling explicitly offers. The optional revoke behavior is also clearly identified.

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

  Usage Guidelines3/5

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

  The description provides a clear context for the tool's operation, especially the 'Requires admin' prerequisite, but it does not explain when to use this tool versus alternatives. No sibling is mentioned, and there is no explicit when-not-to-use guidance. The usage context is implied rather than fully articulated.

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

• link_group_to_communityA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It discloses the admin requirement and the link/unlink semantics, but does not mention side effects, reversibility, error conditions, or what happens to a group after unlinking. This is acceptable but not rich.

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

  Conciseness5/5

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

  Two sentences with no filler. The core behavior comes first and the permission prerequisite is included compactly.

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

  Completeness4/5

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

  For a simple three-parameter tool with no output schema and no annotations, the description covers the operation, the admin requirement, and the target resource. It is slightly thin on post-action effects and edge cases, but generally sufficient for correct invocation.

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

  Parameters3/5

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

  The schema already documents community and groups with 'name or jid' descriptions, and action has an enum plus default. The description adds the conceptual 'subgroup' relationship but does not meaningfully extend the schema's parameter documentation.

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

  Purpose5/5

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

  The description uses a specific verb and resource: moving existing groups into a community as subgroups or removing them. This clearly differentiates the tool from group-creation and community-creation siblings.

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

  Usage Guidelines4/5

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

  The description gives clear context: it operates on existing groups, not newly created ones, and includes the admin-of-both prerequisite. It does not explicitly name alternatives or state when not to use it, 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.

• mark_as_readA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden, and it does well by stating the mutating effects: sending read receipts and clearing the unread badge. It also scopes the action to 'recent' messages, but does not mention reversibility or rate limits; those are secondary for this operation.

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

  Conciseness5/5

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

  A single, front-loaded sentence with no filler. It efficiently captures the action, scope, and side effect in a way that is immediately useful.

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

  Completeness4/5

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

  For a simple two-parameter mutation with no output schema, the combination of description and input schema is sufficient for a correct invocation. The main gaps are explicit sibling differentiation and precise count semantics, but neither blocks a reasonable agent.

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

  Parameters3/5

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

  Schema coverage is 50%, with chat fully documented but count lacking a description. The phrase 'recent incoming messages' hints at what count might limit, but it doesn't explicitly connect count to the number of messages or explain the default/max behavior, so the description only partially compensates.

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

  Purpose5/5

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

  The description names a specific verb ('Send read receipts') and a concrete resource ('a chat's recent incoming messages') plus the observable outcome ('clear its unread badge'). This clearly distinguishes the tool from siblings like mark_as_unread or chat_unread.

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

  Usage Guidelines3/5

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

  The description implies the use case: when a chat has recent incoming messages and the user wants read receipts/badge cleared. However, it does not explicitly name alternatives or state when not to use this tool, leaving the agent to infer boundaries from sibling names.

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

• get_login_qrA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses what the tool returns and when it's needed, but does not mention potential side effects such as whether requesting a new QR code invalidates previous ones, session expiry, or whether this initiates a pairing session on WhatsApp's side.

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

  Conciseness5/5

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

  Two sentences with zero wasted words. The core function is front-loaded in sentence one, and the usage condition is added in sentence two. Perfectly sized for a zero-parameter tool.

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

  Completeness4/5

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

  For a tool of this low complexity (0 params, no output schema), the description covers the essentials: what it returns and when it's needed. Minor gaps include the output format (image, URL, or data URI) and QR expiry behavior, but 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.

  Parameters4/5

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

  The tool has zero parameters, so the schema documents everything there is to know. Per the rubric, 0 params earns a baseline of 4; the description has nothing to add about parameters and doesn't need to.

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

  Purpose5/5

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

  States a specific verb ('Returns'), a specific resource ('the QR code'), and the exact purpose ('to link this device to a WhatsApp account'). It is naturally differentiated from all siblings because no other tool in the list handles authentication or QR codes.

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

  Usage Guidelines4/5

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

  Gives explicit usage timing: 'Only needed the first time, or after being logged out.' This tells the agent when the tool is appropriate and implies it should not be used when already logged in, though it doesn't name alternatives (none exist among siblings).

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

• leave_groupA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral disclosure burden. It clearly warns that leaving cannot be undone without a fresh invite and instructs the agent to always confirm first. This is strong transparency for a simple mutation tool, though it doesn't mention response behavior or side effects beyond the core action.

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

  Conciseness5/5

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

  Two concise sentences with no filler. The core action and the most important safety warning are front-loaded, and every word adds value.

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

  Completeness4/5

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

  For a simple irreversible action, the description covers purpose, consequence, and required confirmation. It could mention response format or permissions, but those are not essential to correct invocation. Overall, it is sufficiently complete for an agent to use safely.

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

  Parameters3/5

  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 both parameters well. The description adds no additional parameter-level detail, but the baseline of 3 applies because the schema handles the semantic load effectively.

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

  Purpose5/5

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

  The description clearly states the action ('Leave') and the resource ('a group or community'), making the tool's purpose unambiguous. It is distinct from sibling tools like update_group or manage_group_participants because it focuses specifically on leaving rather than modifying or managing.

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

  Usage Guidelines4/5

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

  The description gives clear usage guidance by requiring user confirmation before acting and warning about irreversibility. It does not explicitly compare against alternatives, but the unique purpose makes that less critical.

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

• manage_group_participantsA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It does this well by stating an auth requirement (admin status) and a specific failure mode (403 for privacy-blocked adds) with an actionable fallback. It does not mention success responses or other potential errors, but the disclosed details go well beyond a bare mutation statement.

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

  Conciseness5/5

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

  Three sentences with zero fluff. The first sentence states purpose, the second adds the auth prerequisite, and the third gives an error-handling fallback. Each sentence earns its place, and the most important information is front-loaded.

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

  Completeness4/5

  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 annotations and no output schema, the description covers the essential operational facts: what the tool does, the admin requirement, and how to handle a likely error. It lacks an explicit statement of what a successful call returns, but the absence of an output schema and the presence of a clear action enum make this a minor gap.

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

  Parameters3/5

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

  Schema description coverage is 67%, which is moderately high. The participants parameter is well-described in the schema ('People — names, phone numbers with country code, or jids'), and the action enum is self-explaining. The description text does not add parameter-level detail 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.

  Purpose5/5

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

  The description opens with a precise verb and resource: 'Add people to a group, remove them, or change who is an admin.' This clearly covers all four actions in the enum (add, remove, promote, demote) and distinguishes the tool from sibling group-management tools like create_group and update_group, which operate on group settings rather than membership.

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

  Usage Guidelines5/5

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

  The description provides explicit when-to-use and when-not-to-use guidance: 'You must be an admin of the group' sets the precondition, and 'A person whose privacy settings block being added returns status 403 — send them the invite link instead' names a concrete alternative (the group_invite_link sibling tool) and the condition that triggers it. This is exactly the kind of decision-relevant routing an agent needs.

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

• broadcast_messageA
  4.7/5.0
  Behavior5/5

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

  With no annotations present, the description carries the full burden of behavioral disclosure — and it delivers. It reveals the dry-run default, the recipient cap of 50, pacing of a few seconds apart, the privacy property (recipients do not see each other), and the ban risk that justifies the confirm flow. This is far beyond what annotations alone would typically provide.

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

  Conciseness4/5

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

  Three sentences, front-loaded with the core purpose and the critical dry-run/confirm protocol. The ban warning is slightly long but earns its place because it justifies the confirmation gate. Minor trade: the parenthetical '(what a WhatsApp Broadcast List does under the hood)' is helpful context, and the structure places the cap/pacing after the protocol, which is acceptable.

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

  Completeness4/5

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

  For a 6-parameter tool with no output schema and no annotations, this description is quite complete: it specifies the main workflow, limits, pacing, and risk profile. It doesn't explicitly state what the dry-run return looks like or what 'resolved' means for recipients, but the schema covers the skip_unresolved parameter and the overall context is sufficient for an agent to sequence calls correctly.

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

  Parameters4/5

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

  Schema coverage is 100%, so the schema already documents all six parameters. The description adds meaning by explaining the overall send flow (dry-run then confirm=true) and by tying the pacing parameters to the 'paced a few seconds apart' note. It doesn't enumerate each parameter, but at 100% schema coverage it doesn't need to; the dry-run/confirm context is the main added semantic value.

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

  Purpose5/5

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

  The description opens with a specific verb-resource pair — 'Send the same message to many chats, one individual message each' — and immediately distinguishes it from a group message by explaining that recipients do not see each other, which sets it apart from sibling tools like send_message and broadcast_status. This is a clear, specific purpose.

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

  Usage Guidelines5/5

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

  The description is exemplary: it states when to call once (dry run), when to call again after user approval (confirm=true), and explicitly warns against using it for people who did not opt in. It also names the risk context (bans) that should drive an agent's decision to require confirmation. Unlike siblings such as send_message, this tool is clearly meant for multi-recipient broadcast to opted-in contacts.

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