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

Annotations already declare readOnly, idempotent, non-destructive and openWorld. The description adds genuine extra context beyond them: the state is fetched from a gateway, and enabling include_safety triggers 'a second GET request', disclosing an additional round-trip cost that the annotations do not 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, zero filler, front-loading the core read behavior before the optional-parameter note. Every clause 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 carries the return-value burden and does so: it names the fields returned (linked/connected status, plus health readings and overall verdict when requested). Combined with annotations covering the safety profile, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100% and the single parameter is already documented in the schema ('Also read the safety readings (a second GET request). Default false.'). The description largely restates that, adding only the framing that the readings include an 'overall verdict', so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Read this channel's state from the gateway') and immediately enumerates what that state contains ('whether the number is linked and connected'). The sibling tools operate on entirely different resources (chats, contacts, groups), so no differentiation is needed and none is ambiguous.

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 implies the use case (checking a channel's linkage/connection) and gives conditional guidance for include_safety, but never states when to prefer this over another call or any prerequisite/exclusion. Usage is inferable 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?

Annotations already declare readOnly/idempotent/openWorld/no-destructive, so the safety profile is covered. The description adds genuinely new behavior: the call hits WhatsApp live rather than cached data, must not be polled, and surfaces a 429 whatsapp_rate_limited with a retry_after wait — useful beyond the annotations. It does not describe auth requirements or not-found handling.

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, each carrying distinct information (what it reads, the no-poll constraint, the rate-limit remedy), with the purpose front-loaded. Nothing 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?

With no output schema, the description focuses on invocation behavior and error handling, which is the right allocation for a single-resource read. It leaves the failure modes for an invalid or inaccessible community JID unaddressed, so it is strong but not 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% and the single 'community' parameter is documented there with an example JID format, so the description correctly defers. It adds no syntax or format detail beyond the schema, which is the expected baseline rather than added value.

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 ('Read one community') and adds a scoping constraint ('this channel's number belongs to'), which clearly separates it from the list-style siblings like list_community_subgroups. It does not explicitly name the nearest alternative (get_group), so it falls short of a 5.

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

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

Gives actionable timing guidance ('do not poll it') and explains what to do when throttled (wait retry_after on a 429), which is real when-to-use context. It stops short of naming an alternative tool or stating when a different sibling should be used instead.

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, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds genuinely useful context beyond them: the read is against the channel's local contact store and does not hit WhatsApp, which tells the agent the data may be stale/incomplete compared to a live lookup.

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

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

Front-loaded with the core action, then the scoping caveat, then the parameter format. Two compact clauses with no filler; only minor density in the parenthetical.

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 notes the entry is the names the contact store holds, so the agent knows roughly what comes back. It omits what happens when the contact is absent from the store (null vs error), a small remaining 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?

Schema coverage is 100% and the schema already says 'a user JID or a LID', but the description adds a concrete format example (15551234567@s.whatsapp.net), which materially helps the agent construct a valid value.

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 ('read this channel's stored entry for one contact') and immediately scopes it as the local contact store rather than a live WhatsApp lookup. This distinguishes it from the sibling chat/message/group tools, which all operate on other resources.

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 (resolve a stored contact entry locally) and rules out the WhatsApp-query interpretation, but it names no alternative tool and gives no explicit when-to-use/when-not-to-use condition beyond the 'does not ask WhatsApp' scope note.

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, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the call hits WhatsApp live, must not be polled, and a 429 whatsapp_rate_limited response carries a retry_after backoff. That is meaningful operational 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, each earning its place: purpose first, then the live-call/no-poll constraint, then the rate-limit behavior. Front-loaded and waste-free.

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 returned contents (subject, description, settings, participants) and the failure mode (429 with retry_after). Largely complete for a one-param read tool, though it omits any auth/permission prerequisites.

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% on the single 'group' param (JID format example included), so the schema carries the burden. The description adds no parameter-level detail beyond the schema, which is the baseline case for high coverage.

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

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

States a specific verb and resource ('Read one group') and enumerates what is returned (subject, description, settings, participants). This distinguishes it from list_groups by scoping to a single group, 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?

Gives an explicit usage constraint — 'This asks WhatsApp itself; do not poll it' — which is an actionable when-not-to-do instruction. It does not, however, route the agent to an alternative (e.g., list_groups for enumerating), so it falls short of full alternative-naming 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 this a safe read (readOnly, idempotent, non-destructive), so the bar is lower, yet the description adds real behavioral context: the data source is the gateway's own message log, coverage is limited to chats with activity since linking, and results cap at 100 with no paging available.

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 core action and scope before the caveats. Every sentence adds a distinct constraint an agent needs.

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 still discloses the return cap (up to 100) and absence of paging, plus the coverage limitation. Nothing material 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 there is nothing for the description to compensate for; baseline 4 applies. The note about no paging parameters is useful but concerns the API, not input arguments.

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 (chats) and immediately scopes it: chats the gateway has observed on this channel from its own message log. This distinguishes it from a general account chat list and from siblings like list_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?

Clarifies the operating context by explicitly ruling out the full account chat list and noting that chats with no activity since the number was linked are absent. It doesn't name a sibling alternative to use instead, but the scope conditions are clear enough to guide selection.

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

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

Goes well beyond the annotations (which only cover safety/idempotency) by disclosing that the call hits WhatsApp live, that polling is discouraged, and how a 429 throttling response should be handled via retry_after. This is exactly the kind of runtime behavior an agent needs to invoke it correctly.

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 purpose, followed by the two behavioral caveats. 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 read-only list tool with no output schema and full schema coverage, the description covers purpose plus the important rate-limit and freshness behavior. It could mention the shape of what is returned (e.g. group identifiers), 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?

Schema description coverage is 100% and the schema documents the single community parameter with a JID example. The description adds no additional parameter meaning, so the baseline 3 applies.

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

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

States a specific verb and resource with scope: 'List the groups linked to a community.' The community-scoping requirement implicitly separates it from the unscoped list_groups, though no sibling is named 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?

Gives a clear operational directive ('This asks WhatsApp itself; do not poll it') and concrete recovery guidance for the 429 whatsapp_rate_limited case including waiting retry_after seconds. It stops short of naming an alternative tool for other listing needs.

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 read-only, idempotent, non-destructive, open-world behavior. The description adds value beyond them: it states the data comes from WhatsApp itself (fresh, not cached), warns against polling, and explains the 429 whatsapp_rate_limited response with retry_after. Return shape and pagination behavior remain unstated.

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, followed by the polling warning and the rate-limit contract. Every sentence carries actionable information 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 no-parameter, no-output-schema read tool, the description supplies the important operational context (source of truth, no polling, 429 handling). It stops short of describing what each returned group contains, which would be the only remaining gap given there is no output schema.

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 per the rubric the baseline is 4. The description correctly implies a no-argument call, and there are no parameter semantics to add.

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) plus resource (WhatsApp groups) and scopes it to "this channel's number is in," so an agent knows it returns group membership for the connected number. It does not explicitly distinguish itself from the group-related sibling get_group or from list_chats, so it falls short of 5.

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

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

"do not poll it" is an explicit usage constraint, which is more than nothing, but there is no guidance on when to prefer this over get_group or list_chats, and no stated prerequisites. Usage is implied rather than framed against 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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: lid_lookup merging behavior, the merge and source_chat indicators, history_sync provenance, pagination via next_before, and that every page read is recorded in the channel's API access records.

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 purpose and scoping constraint are front-loaded in the first clause. The remaining sentences are dense but each carries distinct operational information, though the middle section is information-rich enough to be slightly heavy for a single paragraph.

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 carries return-value context well by naming the fields an agent will see (merge, source_chat, sender_jid, sender_lid, next_before) and explaining provenance limitations. Nothing needed 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 goes further by explaining the pagination flow (next_before -> before), restating the default limit of 50, and clarifying that chat can denote either a person or a group.

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 (read one conversation from this channel's message log) and immediately scopes it to a person or a group. It is clearly distinguishable from siblings like list_chats, get_contact, or get_group, which list rather than read message history.

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: read a conversation once you know the chat, and paginate by passing next_before as before. However, it never states when to prefer this tool over siblings or any exclusions/prerequisites, so guidance is only inferable rather than explicit.

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