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

No annotations are provided, so the description carries the full burden. It does disclose a real side effect — a QR code is written to a configured local file — which is valuable behavioral information an agent would not otherwise know. However, it says nothing about auth/session requirements, whether the call blocks while waiting for pairing, or whether the operation is read-only in any meaningful sense.

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

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

Two short sentences, no filler, and the core purpose is front-loaded ahead of the side-effect detail. Every sentence contributes something.

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

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

For a simple zero-parameter status tool this is close to adequate, but with no output schema and no annotations the description should at least sketch what state values can come back or where the 'configured local file' path is set. Those gaps are minor but real.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool is 4. The mention of a 'configured local file' hints at external configuration but does not map to any input.

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: 'Show local pairing and connection state.' The domain (pairing/connection) is clearly distinct from every sibling, which all deal with chats, messages, or media. It stops short of explicitly naming an alternative or sibling, so it lands at 4 rather than 5.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as the chat/message tools. The agent must infer that this is the tool to call to check or establish pairing, and whether it should be called before other operations is left unstated.

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

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

With no annotations, the description carries the full burden. It adds real behavioral context by naming the destination ('configured local directory') and source constraints (cached, allowlisted), but says nothing about overwrite behavior, failure modes, or required permissions for a filesystem-writing operation.

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

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

A single front-loaded sentence with the verb first and zero filler. Every clause (source constraints, destination) carries information.

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

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

There is no output schema, so the description should state what is returned (e.g., a file path or bytes) and how failures behave, but it does neither. Combined with zero parameter documentation, an agent lacks enough to invoke this reliably.

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

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

Schema description coverage is 0% for two required parameters, so the description must compensate. It only alludes vaguely to 'message' and 'directory' and never maps to chatId or messageId or explains their format, leaving both required params undocumented.

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

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

States a specific verb and resource ('Download media') plus the scope constraint ('from a locally cached allowlisted message'), which clearly distinguishes it from the send_media sibling. It stops short of naming an alternative, so it is clear but not sibling-routing.

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

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

The phrase 'locally cached allowlisted message' implies the precondition for use (the message must already be in the local cache and the chat/media allowlisted), but there is no explicit when-to-use versus send_media or when-not guidance. Usage is implied rather than stated.

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

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

With no annotations, the description carries the full burden, and it does disclose two useful traits: results come from a 'local session cache' and the result set is uncapped. However, it omits the practical consequences of an unbounded fetch (volume, performance, pagination) and whether the cache can be stale relative to server state.

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

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

A single sentence with the differentiator front-loaded and zero filler. Nothing to trim and nothing buried.

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

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

For a simple zero-required-parameter read tool with no output schema, the description covers the core purpose, but it leaves the one optional parameter unexplained and does not address the sibling list_chats it is clearly meant to complement. Adequate but with visible gaps.

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

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

Schema description coverage is 0%, so the description must explain the single 'limit' parameter, and it does not mention it at all. Worse, the headline framing 'List ALL ... not capped' sits in tension with a limit parameter capped at 10000, so the agent gets no guidance on how limit interacts with the 'ALL' framing.

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 clear verb ('List') and resource ('chats') plus the scope qualifier 'ALL ... not capped by the default list'. It implicitly distinguishes itself from the sibling list_chats via the 'default list' reference, though it never names that sibling outright.

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

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

The parenthetical '(not capped by the default list)' implies when this tool is preferred — when the default capped listing is insufficient — but it never says to use list_chats otherwise, nor does it name any alternative. Usage is inferable rather than stated.

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

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

With no annotations, the description carries the full burden. It usefully discloses the 'allowlisted chat' constraint and names the underlying mechanism (Baileys fetchMessageHistory), but says nothing about pagination termination, limits, failure behavior, or what happens when beforeMessageId is omitted.

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

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

Two short sentences, front-loaded with the action and scope, followed by the key paging instruction. 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 3-param tool with no annotations, no output schema, and 0% parameter coverage, the description covers the essential paging flow but omits limit semantics and any return/behavioral detail. Adequate but with clear gaps.

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

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

Schema coverage is 0%, so the description must compensate. It explains beforeMessageId's purpose (page backward) and implicitly scopes chatId to allowlisted chats, but the limit parameter's semantics (default, max 100) are left entirely to the schema with no added meaning.

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

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

States a specific verb (pull) and resource (older messages) and scopes it to an 'allowlisted chat', which distinguishes it from search_messages and read_messages that operate on current messages. It does not explicitly name a sibling, so it falls just short of the top score.

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?

Clear usage context: fetch older messages and use beforeMessageId to page backward, implying it is the pagination/backfill tool rather than the search tool. No explicit when-not condition or named alternative is given.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose one important trait — results come from the local session cache, implying possible staleness or incompleteness — but says nothing about permissions, pagination, ordering, or what happens when the cache is empty.

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

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

One short sentence with the scoping constraint front-loaded and zero filler. It is appropriately sized, though the extreme brevity leaves little room for the usage and parameter context 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?

For a list tool with no annotations and no output schema, the description should clarify return shape, ordering, and pagination semantics. It covers only the data source, leaving the agent under-informed about what a call actually yields.

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

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

The single parameter (limit) has 0% schema description coverage, exposing only type and min/max. The description adds no information about what limit controls, its default, or whether truncation is signalled.

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?

Names a specific verb and resource ("List chats") and adds a meaningful scope qualifier ("visible in this local session cache") that implies a cached-snapshot view rather than a server fetch. It does not, however, explicitly distinguish itself from the sibling fetch_all_chats, leaving the agent to infer which one talks to the network.

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

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

There is no statement of when to use this tool versus fetch_all_chats, search_messages, or fetch_message_history. The word "visible" hints at a scoping condition, but no explicit when/when-not guidance is given.

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

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

With no annotations, the description carries the full burden, but it does disclose two real traits: results come from a local cache (no network fetch) and access is restricted to an 'allowlisted' chat. It does not state read-only nature explicitly, pagination/ordering behavior, or what happens when the cache is empty or the chat is not allowlisted.

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

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

A single front-loaded sentence with no filler. The scope constraint (recent, cached, single allowlisted chat) appears immediately.

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

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

For a two-parameter read tool with no output schema and no annotations, the description establishes the source (cache) and scope but leaves the limit semantics, default paging, result ordering, and error conditions unspecified. Adequate but with clear gaps.

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

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

Schema description coverage is 0% for two parameters. The description only weakly implies that chatId targets a single chat and that recency is bounded, but it says nothing about the 'limit' parameter, its 1-100 range, or how limit interacts with 'recent'. The schema does the heavy lifting and the description does not compensate.

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

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

Clear specific verb (read) and resource (messages) with meaningful scope qualifiers: 'recent' and 'locally cached'. It implicitly distinguishes itself from fetch_message_history (network/history) and search_messages (query-based), but never names a sibling, so differentiation requires inference.

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

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

The phrase 'locally cached' and 'recent' implies when this is appropriate versus fetching history, but there is no explicit when-to-use or when-not-to-use statement and no sibling is named. Usage is inferable rather than stated.

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

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

With no annotations, the description carries the full behavioral burden and does disclose two meaningful traits: the search is limited to the local cache (results may be incomplete) and it never sends messages. It omits other relevant behavior such as pagination via limit, auth requirements, or result ordering.

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

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

Two short sentences, zero filler, with the scoping constraint front-loaded. Nothing could be removed without losing information.

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

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

No annotations and no output schema, and the description leaves all three parameters unexplained, including how limit and chatId narrow the search. For a search tool with an undocumented input shape, this is insufficient beyond the useful local-cache caveat.

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

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

Schema description coverage is 0% for three parameters, so the description must compensate and it does not — query, limit, and chatId are never mentioned or explained. An agent gets no help mapping the parameters to search scoping or result size.

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 ("Search") and resource ("message text") plus a qualifier ("locally cached") that sets it apart from read_messages or fetch_message_history. It does not name a sibling explicitly, so differentiation is only implied by the cache scoping.

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?

"Locally cached" implicitly tells the agent this only covers already-synced data, which is useful context for choosing between this and fetch_message_history. However, there is no explicit when-to-use, no exclusion, and no named alternative, so an agent must infer the routing.

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

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

With no annotations, the description carries the disclosure burden and does well on the critical items: it states the authorization/gating requirement (WHATSAPP_SENDING_ENABLED=true) and two allowlist constraints (source directory, recipient chat). It omits failure behavior, size limits, and whether a sent message can be recalled, so it stops short of full coverage.

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

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

A single dense sentence front-loads the action and resource, then appends the hard constraints. No filler, no repetition of the tool name.

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

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

For a 4-parameter, 0%-schema-coverage mutation tool with no annotations and no output schema, the description covers the path and recipient constraints well but leaves the optional caption undocumented and says nothing about outcomes or failure modes. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate and it partially does: filePath gains the crucial 'regular file inside WHATSAPP_OUTBOUND_MEDIA_DIRS' constraint and chatId the 'allowlisted chat' constraint, both absent from the schema. However caption (optional, maxLength 2048) is never mentioned, and the mediaType list merely restates the schema enum.

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

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

Specific verb ('send') plus a precise resource enumeration (image, video, audio, document, sticker) and the file source. An agent can tell this is the outbound media path rather than the text path used by send_message, 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 clear preconditions for use: the file must be a regular file inside WHATSAPP_OUTBOUND_MEDIA_DIRS, the chat must be allowlisted, and WHATSAPP_SENDING_ENABLED=true must be set. No explicit 'use X instead' routing to send_message or download_media, but the operating context is unambiguous.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses two behavioral constraints (allowlist target, env-flag gating) beyond the schema, but says nothing about failure behavior on non-allowlisted chats, rate limits, idempotency, or what the response contains for a write operation.

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

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

Two short sentences with zero filler, and the primary action is front-loaded ahead of the gating prerequisite.

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 write tool with no annotations, no output schema, and 0% parameter coverage, the description covers the critical enablement gate and target restriction but omits what a successful call returns and how errors surface. Adequate to attempt the call, incomplete for confident use.

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

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

Schema description coverage is 0% — the schema gives types and length bounds but no semantics. The description only gestures at 'chat' via 'allowlisted chat' and does not explain the chatId format (phone number vs JID) or any other meaning for either parameter, so it fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('Send a text message') plus the scoping qualifier 'to an allowlisted chat'. The word 'text' implicitly separates it from the sibling send_media, though the sibling is never 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?

Discloses a real prerequisite ('Requires WHATSAPP_SENDING_ENABLED=true') and the allowlist constraint, which tells the agent when the call will succeed. However, it never states when to prefer this over send_media or any alternative, leaving routing to inference.

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