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 implies a read-only check and specifies the phone format, but omits whether the operation requires a valid session, has side effects, is rate-limited, or what happens on error. The word 'Check' suggests safety but does not confirm it.

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

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

A single, front-loaded sentence with no wasted words. The format constraint is placed immediately after the resource, which is efficient and clear.

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

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

The tool is simple and has an output schema, so return values need not be described. However, the required 'session' parameter is completely unexplained, and with no annotations the description should do more to clarify behavior such as session requirements or safety.

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. It meaningfully defines the 'phone' parameter (digits only, with country code) but says nothing about the required 'session' parameter, leaving half the inputs 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?

The description states a specific verb ('Check') and resource ('phone number has WhatsApp'), making the tool's purpose immediately clear. It does not explicitly differentiate from siblings, but the siblings are session/chat/messaging operations, so overlap is minimal.

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

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

Usage is implied by the nature of a lookup, but there is no explicit guidance on when to use this tool versus alternatives or prerequisites (e.g., needing an active session). The parenthetical format hint is helpful but does not constitute usage 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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It mentions the QR-code dashboard step, but does not explain side effects, persistence, authentication requirements, or what the 'start' default implies.

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

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

The description is front-loaded and consists of two short, purposeful sentences. It avoids waste, though the second sentence is an operational instruction rather than a usage guideline.

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?

An output schema exists, but the description still omits parameter meaning, usage context, and behavioral details for a mutation tool with no annotations. The QR-code note helps slightly but is not enough for complete context.

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% and the description does not mention either parameter. The required 'name' parameter and the optional 'start' parameter are left completely unexplained.

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: 'Create a new WhatsApp session.' It is clear what the tool does, but it does not explicitly differentiate itself from sibling tools like waha_start_session or waha_get_session.

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 only says to scan the QR code with the dashboard after creation. It gives no guidance on when to use this tool versus waha_start_session or other session-related siblings, nor does it state prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the full burden, yet it says nothing about read-only semantics, permissions, error behavior for unknown chat_ids, or what 'details' includes. The only behavioral hint is the implicit read nature of 'Get'.

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 purpose, no filler. The only weakness is that the second sentence is a bare format note rather than carrying more of the missing context.

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?

An output schema exists, so return values need not be described. However, with a required undocumented 'session' parameter and no usage guidance, the description leaves real gaps for an agent invoking this tool for the first time.

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. It does explain chat_id's expected format ('549...@c.us' or '...@g.us'), which is genuinely useful, but the required 'session' parameter is left entirely undefined in both schema and description.

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

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

States a specific verb ('Get details') and resource ('a chat'), which is clearly narrower than the sibling waha_list_chats and distinct from waha_get_chat_messages. It does not explicitly name a sibling to contrast with, so it stops short of a 5.

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

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

Usage is only implied: an agent can infer this is for fetching one chat's metadata versus listing chats or reading messages. There is no explicit when-to-use, precondition, or alternative named.

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

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

With no annotations, the description must carry the full behavioral burden. It discloses the sort order (newest first) and read-only intent, but says nothing about pagination semantics, session requirements, or that download_media triggers media fetching — a side effect an agent should know before setting it.

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

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

Two short, front-loaded sentences with zero filler — the core operation comes first and the dependency second. Brevity is appropriate, though it edges toward under-specification given the schema gap.

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?

An output schema exists, so return values need no explanation. But for a five-parameter tool with no annotations and no schema descriptions, the description is too thin: an agent cannot infer what session means, how limit/offset paging behaves, or the cost of download_media.

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% across five parameters, so the description must compensate and largely does not. Only chat_id's provenance is addressed; session, limit, offset, and download_media are left entirely undocumented, including their defaults and interaction.

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?

"Read messages from a chat" gives a specific verb plus resource, and the ordering note ("newest first") scopes the result set. It implicitly separates from waha_list_chats and the send_* tools, but never names an adjacent read sibling like waha_get_chat to draw the line 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?

"Use the id from waha_list_chats" is a real prerequisite that tells the agent where chat_id comes from. However, there is no statement of when to prefer this over waha_get_chat, and no exclusions or paging guidance for repeated calls.

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 it only weakly implies read-only via 'Return'. It says nothing about whether the session must be started/authenticated, what happens if the session is not logged in, or whether errors are raised versus an empty result — all material for a session-scoped account 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?

A single front-loaded sentence with the resource and the payload stated up front and no filler. Nothing to trim.

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

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

An output schema exists, so return values need no explanation, and the tool is simple. But with zero annotation coverage and an undocumented parameter, the description should at minimum say the session must exist/is authenticated and how the session argument is identified.

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 schema gives the agent only a bare 'session' string. The phrase 'linked to a session' does clarify that the parameter selects which session's account is returned, but it adds no format detail (session name vs. id) or validity constraints.

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 ('Return') and a specific resource (the WhatsApp account linked to a session), and enumerates the returned fields (id, lid, pushName), so the agent knows exactly what it gets. It does not, however, contrast itself with near neighbors like waha_get_session or waha_status, which look similar from the name alone.

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

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

Usage is only implied: the field list (id, lid, pushName) signals 'call this when you need the account identity behind a session.' There is no explicit when-to-use statement and no routing away from waha_get_session or waha_status, which an agent could plausibly pick 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read operation by the word 'Get', but says nothing about what happens for contacts without a picture, whether group IDs are accepted in the same field, permissions, or failure behavior. An output schema exists so return shape is partly covered, but the behavioral surface is still largely undisclosed.

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

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

A single, front-loaded sentence with no filler. It is appropriately sized, though its brevity is partly the cause of the missing session semantics rather than a model of efficiency.

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

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

The tool is a simple read with an output schema, so the description does not need to explain return values. However, with no annotations at all and a required 'session' parameter left undefined, an agent could not confidently invoke it without guessing at the session argument.

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 both parameters. It partially helps by indicating the identifier can be a contact or a group, but 'session' — a required parameter — is completely unexplained with no hint about whether it is a session name, ID, or default.

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

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

The description gives a specific verb and resource: retrieve the profile picture URL for a contact or group. This is unambiguous and clearly distinct from siblings like waha_get_me or waha_get_chat, though it does not explicitly name those alternatives.

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

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

There is no statement of when to use this versus alternatives, no preconditions, and no exclusions. The only hint is that the target may be 'a contact or group', which does not tell the agent anything about selection criteria.

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 discloses the returned fields, which suggests a read operation but never states it is non-mutating or that it fails for unknown sessions. The existence of an output schema lowers the need to describe return values in detail.

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

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

A single short sentence, front-loaded with the verb and result. It is efficient, though it leaves no room for the missing parameter and error context.

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

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

For a one-parameter read tool with an output schema, the basics are covered, but the unspecified 'session' parameter and the absence of any error or not-found behavior leave meaningful gaps given there are no annotations.

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

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

Schema description coverage is 0% and the sole required parameter 'session' is undefined — the description never says whether it is a session name, ID, or default. Nothing in the description compensates for the undocumented parameter.

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

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

States a specific verb and resource ('Get one session') and names the returned content (status, linked WhatsApp account). The singular 'one' implicitly contrasts with waha_list_sessions, though that sibling is never named.

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

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

Usage is only implied by the singular lookup phrasing; there is no explicit guidance on when to prefer this over waha_list_sessions or waha_status, and no mention of behavior when the session identifier does not exist.

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. 'List' plus 'newest first' does convey read-only semantics and result ordering beyond the schema, but it says nothing about pagination behavior, what happens with an invalid/inactive session, or result limits relative to the limit param.

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

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

A single tight sentence with the key ordering fact front-loaded, no filler. It is arguably under-specified rather than verbose, but nothing in it is wasteful.

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

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

With zero schema coverage, no annotations, and three parameters, the definition leaves an agent guessing about limit/offset semantics and session preconditions. The existence of an output schema covers return values, but the call-side gaps remain substantial.

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 mostly does not: 'for a session' weakly covers the required session param, while limit and offset receive no explanation of their meaning, defaults, or pagination interaction.

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+resource ('List recent chats') and scopes it to a session, with ordering ('newest first') clarified. It is distinguishable from waha_get_chat and waha_get_chat_messages by implication, but it never explicitly names those siblings.

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

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

There is no statement of when to use this vs. alternatives (e.g., waha_get_chat_messages for message content, waha_get_chat for a single chat), and no prerequisites such as whether the session must be started first.

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 disclosure burden, yet it says nothing about whether stopped sessions are returned by default (only implied via the parameter), whether the call requires an authenticated/running server, or what ordering/scope the listing has. The mutation-free nature of a list operation can be inferred, but little else.

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

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

Two short sentences with the purpose front-loaded and the parameter note second; no wasted clauses. It is tight, though the second sentence could have been folded into a fuller usage statement rather than standing alone as a bare default note.

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

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

With an output schema present, return values need not be described, and there is only one optional parameter, so the bar is low and the description mostly meets it. For a read tool with zero annotations, however, it omits any environment/auth assumptions an agent might need before calling.

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 does explain include_stopped as the switch that surfaces stopped sessions, implying the default excludes them. That covers the sole parameter adequately but adds no detail on how 'stopped' is defined or whether the flag changes the response shape.

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?

"List WhatsApp sessions" states a specific verb and resource, clearly distinguishable from waha_get_session (single session) and waha_status by naming the collection being enumerated. It does not explicitly call out siblings, but the verb+resource combination is unambiguous.

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

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

The description offers no guidance on when to use this list tool versus waha_get_session, waha_status, or waha_list_chats; the second sentence is parameter semantics rather than usage context. An agent must infer the selection criteria from tool names alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a mutation but does not disclose whether read receipts are sent to the other party, whether the unread counter is reset server-side, or whether the operation requires an active session — all material for a write action on a messaging account.

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

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

A single front-loaded sentence with no filler. It is efficient, though the extreme brevity contributes to the unspecified areas rather than being solely a virtue.

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?

An output schema exists, so return values need not be explained. However, with no annotations and no parameter documentation, the description leaves the agent without any behavioral context for a mutation on a live messaging session — a gap this simple tool's description should have covered.

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

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

Schema description coverage is 0%, and the description only implicitly identifies 'chat' as the target. It says nothing about the required 'session' parameter (which session/account the chat belongs to) or the expected chat_id format, leaving both parameters documented nowhere.

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 ('Mark ... as read') and resource ('all messages in a chat'), which clearly separates it from siblings like waha_get_chat_messages or waha_list_chats. It does not explicitly name an alternative, but the action is unambiguous.

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

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

No indication of when to use this versus reading messages via waha_get_chat_messages, nor any prerequisites (session must be running, chat must exist). The agent must infer usage entirely from the one-line purpose.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It implies a send/mutation operation but does not mention permission requirements, delivery behavior, source precedence if multiple file inputs are supplied, or other operational constraints.

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

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

The description is a single front-loaded sentence with no wasted words. It efficiently conveys the core action and supported source types.

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 an 8-parameter mutation tool with no annotations and no schema descriptions, the definition is under-specified. It should explain required session/chat_id context and clarify how filename, mimetype, and multiple source inputs are handled.

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%, and the description only documents the source-related parameters (url, path, data_base64) and caption. It leaves the required session and chat_id parameters and the filename and mimetype parameters unexplained.

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

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

The description states a specific verb and resource: "Send a document" from one of three source types, with an optional caption. It is clear enough to distinguish from text/image sending, but it does not explicitly name or differentiate the sibling tools.

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

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

The description explains the available source types but gives no guidance on when to use this tool instead of siblings like waha_send_image or waha_send_text. There are no exclusions, prerequisites, or decision rules for choosing URL, path, or base64 input.

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 exist, so the description carries the full behavioral burden and it discloses very little: it doesn't say whether url must be publicly reachable, whether path is server-local, whether the source parameters are mutually exclusive, or what happens on failure. For a mutation tool with zero annotation coverage this is a substantial gap.

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

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

It is a single tight, front-loaded sentence with no wasted words, which is good. But its brevity comes at the cost of omitting information the agent actually needs, so the concision is partly under-specification.

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?

An output schema exists, so return values needn't be explained, but with 8 undocumented input parameters and no annotations the description leaves the agent guessing about session targeting, source exclusivity, and the filename/mimetype overrides.

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% across 8 parameters, so the description must compensate and it largely doesn't: it implies url/path/base64 are alternative sources but never says they are mutually exclusive or which to prefer, and it is entirely silent on session, chat_id, filename, and mimetype.

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

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

The description states a specific verb and resource ('Send an image') and enumerates the three accepted image sources plus the optional caption, which is clear. It does not, however, distinguish this from the sibling waha_send_file, so an agent cannot tell from the description alone which one to pick for a picture.

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

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

There is no guidance on when to use this versus waha_send_file, no statement of the obvious precondition that the session must be started, and no indication of what to do when both url and path are supplied.

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 at all, so the description carries the full burden: it never says whether a started/connected session is required, what happens on failure, whether the message is queued or delivered immediately, or whether it can be retracted. Only the reply-linking behavior is hinted at.

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 followed by the one non-obvious option. Nothing is repeated from the schema and nothing is wasted.

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

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

For a 4-parameter mutation with zero annotation and zero schema description coverage, the definition is too thin; an output schema exists so return values needn't be explained, but session preconditions and identifier formats are 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 0% across 4 parameters, so the description must compensate and it only clarifies reply_to ('as a message id'). The format of chat_id (e.g. the WhatsApp JID form) and the meaning/scope of session are left entirely 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 ('Send a text WhatsApp message'), which cleanly separates it from siblings waha_send_image and waha_send_file. It does not explicitly call out those siblings, but the 'text' qualifier does the differentiation implicitly.

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

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

No guidance on when to use this versus the other send tools, and no prerequisites such as requiring an active session (waha_start_session) before sending. The only usage-like statement is the optional reply_to 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?

No annotations are provided, so the description carries the full burden and discloses almost nothing: not whether the indicator auto-expires, whether calls are idempotent, whether an inactive session or nonexistent chat errors out, or whether there are rate limits. It effectively restates the function name, which is a significant gap for a state-mutating call on a messaging platform.

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

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

A single short, front-loaded sentence with zero filler. It is efficient, though the brevity reflects under-specification rather than tight writing of complete 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?

An output schema exists so return values need not be explained, but with no annotations and 0% parameter coverage the description leaves the agent without session requirements, chat_id format, or side-effect behavior. For a three-parameter tool requiring a live session, this is incomplete.

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%, and the description only implicitly covers the 'typing' boolean via 'show or hide'; 'session' and 'chat_id' remain undefined, notably the required chat identifier format (e.g. WhatsApp JID). With three parameters and no schema documentation, the description does not 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?

Names a specific state change (show/hide) on a specific resource (the 'typing...' indicator) in a chat, which separates it cleanly from siblings like waha_send_text or waha_mark_chat_read. It stops short of stating scope, e.g. that it acts on an existing session, but the core purpose is unambiguous.

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

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

No indication of when to use this versus simply sending a message, whether a typing indicator must precede waha_send_text, or whether an active session is a prerequisite. The agent must infer all triggering conditions from the name alone.

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

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

With no annotations, the description carries full behavioral burden. It usefully discloses that QR-code scanning via the dashboard is required, but it does not explain permissions, side effects, what happens if the session is already running, or how the start operation behaves.

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

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

Two short sentences, front-loaded with the core action and followed by the key operational detail. There is no wasted text.

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?

An output schema exists, so return values need not be explained. However, for a lifecycle mutation tool with no annotations and an undocumented required parameter, the description should do more to cover prerequisites and state behavior.

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

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

There is one required parameter, 'session', with 0% schema description coverage. The description refers to 'its QR code' but does not explain that 'session' is the session identifier/name or how to obtain it, so the parameter semantics remain under-specified.

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: start a stopped WhatsApp session. It is clear what the tool does and implicitly distinguishes itself from create_session by requiring an already stopped session, though it does not name siblings explicitly.

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

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

The phrase 'stopped WhatsApp session' gives implied usage context: use this for existing stopped sessions rather than new ones. However, it does not explicitly say when to use waha_create_session or waha_stop_session instead, nor does it state prerequisites or failure conditions.

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 burden. It discloses that this checks connectivity and returns status/version, but it does not state safety profile, auth requirements, failure behavior, or whether it has side effects.

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

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

A single front-loaded sentence with no wasted words. It communicates the action and return content efficiently.

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

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

For a zero-parameter status tool with an output schema, the description is complete enough: it says what is checked and what is returned. The output schema can carry detailed return shape.

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

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

The tool has zero parameters, so there are no parameter semantics to explain. The baseline for zero-param tools is 4, and the description does not need to add parameter detail.

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: checking WAHA connectivity and returning server status/version. It is clearly distinct from session, chat, and messaging siblings.

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

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

The usage is implied by 'Check WAHA connectivity,' but the description does not explicitly say when to use this versus other diagnostic or identity tools such as waha_get_me. No exclusions or alternatives are named.

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

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

With no annotations, the description carries the full burden. It usefully discloses one key behavioral trait: stopping does not delete session data. It does not describe permissions, whether the stop is reversible, or what happens to connected clients, leaving meaningful gaps for a lifecycle mutation tool.

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

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

A single compact sentence with the action front-loaded and the important non-destructive scope stated immediately. 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?

An output schema exists, so return values need not be explained. For a one-parameter lifecycle tool this is reasonably complete on purpose, but it omits parameter meaning and operational side effects, which are still relevant with no annotations.

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

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

Schema description coverage is 0%, and the description never mentions the sole 'session' parameter. The parameter name is self-explanatory enough to infer, but the description adds no format, source, or example guidance beyond the bare schema property.

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

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

The description states a specific verb and resource: 'Stop a running WhatsApp session.' It also clarifies scope with 'without deleting its data,' distinguishing the operation from deletion. It does not explicitly compare against siblings like waha_start_session, but the purpose is clear.

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

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

Usage is implied by 'running' — use it on an active session — and the data-preservation note suggests caution around destructive alternatives. However, it never explicitly says when to use this tool versus waha_start_session or other lifecycle tools, nor does it state prerequisites.

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 provided, the description carries the behavioral burden. It discloses that the tool captures the current screen and returns a saved file path, but it does not mention session prerequisites, permissions, or where the file is saved.

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

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

The description is a single efficient sentence with the action and return value front-loaded. There is no wasted text.

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?

An output schema exists, so return values need not be detailed further. However, for a tool requiring a session parameter with no schema description and no annotations, the description is only minimally complete because it does not explain the session prerequisite or parameter semantics.

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 should compensate for the undocumented session parameter. It never mentions what the session parameter means or how it affects the screenshot capture, leaving the required parameter unexplained.

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: capture the current WhatsApp Web screen. It also clarifies the return behavior by saying it returns the saved file path, making the tool's purpose immediately distinguishable from sibling session and messaging tools.

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

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

The description implies the tool is for capturing the current screen, which gives some usage context. However, it does not explicitly state when to use it versus alternatives or mention any prerequisites such as an active session.

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