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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is largely covered by structured data. The description adds one piece of real context — that cancellation affects the local queue only — but says nothing about idempotency, reversibility, or failure modes when the post is not in the queue.

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 qualifier is parenthetical and immediate. It is efficient, though the parenthetical is terse enough that its implication (no network/remote effect) must be inferred.

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, non-destructive toggle with annotations present and no output schema, the description is minimally adequate. It leaves the id's origin and the post-cancellation state (removed vs. merely skipped) unexplained, which an agent would want 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%: the only parameter is documented as a bare string with minLength 3. The description does not clarify that this is the id returned by schedule_post/list_scheduled_posts, which is the key semantic an agent needs. With low coverage the description should compensate and it does not.

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

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

States a specific verb and resource ("Cancel a queued post") plus a scope qualifier ("local queue only") that separates it from remote/other cancellation semantics. It does not name or contrast any sibling such as list_scheduled_posts or run_due_posts, so an agent gets the action but no routing cue.

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 action itself: you call this to cancel something sitting in the queue. There is no guidance on prerequisites (where the id comes from), what happens if the post is already running/dispatched, or which sibling to use 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 readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds meaningful behavioral context on top: the confidentiality guarantee ('Never displays credentials') and the shape of the state values (authorized, notAuthorized…), which help an agent interpret the response.

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

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

Two sentences, no filler, with the primary output content (provider + state) front-loaded before the credential caveat. Every clause 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?

No output schema exists, so the description must describe the return; it covers the two main pieces (provider and instance state) plus the credential exclusion. It stops short of fully enumerating the status object's fields, a minor gap for a simple zero-argument status probe.

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

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

Zero parameters, so the baseline of 4 applies. There is no parameter syntax to explain and the description correctly says nothing extraneous about inputs.

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

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

States a specific verb ('Shows') and concrete resources: the configured provider (Green API instance and/or WhatsApp Cloud API) and the instance state (authorized, notAuthorized). This is plainly distinguishable from the messaging-oriented siblings like post_message or list_groups, though it never names an alternative to actively route the agent.

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 never says when to call this tool, when not to, or what alternatives exist. An agent could infer it is a pre-flight connectivity/config check, but nothing in the text supplies that framing or any 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered structurally; "Sends nothing" largely restates that. The description does add one genuinely new behavioral fact — that output is rendered with WhatsApp formatting — but says nothing about what the draft looks like, its length, or how it differs from the sent message.

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

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

Two tight sentences with no filler: the purpose and kind list come first, and the differentiator "Sends nothing" is front-loaded at the end where it lands hardest. Nothing is padding.

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

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

With 9 parameters and no output schema, the description should say what actually comes back (a formatted post body?) and how it is consumed downstream; neither is stated. It covers the core intent and read-only nature adequately, but leaves the return contract and most parameter behavior undocumented.

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 9 parameters, so the description carries the full burden and largely fails to: it enumerates only the kind values (already a self-documenting enum) and vague "facts the user gives." Date, link, tone, emoji, options, location, and details are never explained, and "WhatsApp formatting" only loosely hints at tone/emoji.

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 (draft) and resource (WhatsApp post), enumerates the supported post kinds, and adds the key scope qualifier "Sends nothing," which separates it from the sending siblings like post_message and schedule_post. An agent can identify the tool without opening the schema.

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

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

"Sends nothing" clearly frames this as a compose/preview step rather than a send, which is exactly the context an agent needs to reach for it instead of post_message. It does not name the follow-up sibling (post_message or schedule_post) or state exclusions explicitly, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value by naming the returned fields and the upstream Green API method, but says nothing about auth requirements, error/empty-group behavior, or rate limits.

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

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

A single terse fragment with no padding and the key content front-loaded. It is efficiently sized, though its telegraphic style reads as a list of fields rather than a clear statement of action.

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

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

For a one-parameter read tool with no output schema, the description does list the fields returned, which partially compensates. However, it leaves the groupId format and the tool's place relative to list_groups unexplained, so it is only minimally adequate.

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% and the single groupId parameter is undocumented in both schema and description. The description gives no hint about the expected format (e.g., a WhatsApp '@g.us' identifier), 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?

The description is a noun phrase enumerating the fields returned (subject, description, owner, participant count/admins) with a parenthetical pointing at the underlying 'getGroupData' call. The verb is only implied, so the reader must infer 'retrieve details for one group'. It weakly differentiates from the sibling list_groups but never states the distinction 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives despite list_groups being an obvious sibling for enumerating groups. The agent must guess the context 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?

readOnlyHint=true and openWorldHint=true already tell the agent this is a safe, external read, so the bar is lower. The description adds the account-scoping constraint and that ids are returned, but says nothing about result size, pagination, or 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?

A single compact sentence with the scope stated first and the optional parameter tacked on; no filler. Slightly denser punctuation than ideal, but nothing 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 one-optional-parameter read tool with no output schema, the description covers scope, what is returned (ids), and the filter. Only return-set shape and pagination are left implicit, which is minor at this complexity.

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% and the lone 'filter' property is completely undescribed in the schema, so the description carries the burden. It does so by identifying it as a name filter and as optional, which is exactly what an agent needs; only the matching semantics (substring vs exact, case) are unstated.

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

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

States a specific verb and resource ('List the WhatsApp groups') and scopes it to the account's linked number, which separates it from sibling group_info (single-group detail). It does not name a sibling explicitly, so it stops short of the top mark.

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?

'with ids for other tools' signals the discovery role and the context in which to call it, while 'Optional name filter' tells the agent the filter is optional. No when-not-to-use or explicit alternative is offered, so it is clear context rather than full routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: no pagination, ordering, result limits, or default-filter behavior, and its word "queued" does not match the schema's "scheduled" enum value, which mildly muddies rather than clarifies.

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 brevity shades into under-specification rather than tightness.

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 filtering list tool with no output schema and a 0%-documented parameter, the description should cover default scope, ordering, and result shape. None of that is present, leaving the agent to guess what an unfiltered call returns.

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 sole status parameter. It names four states but never maps them to the parameter, never mentions the "all" enum option, and never states the default when status is omitted.

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 ("scheduled posts") plus the status scope it covers. An agent can tell this is the enumeration tool, but it never contrasts itself with siblings like cancel_scheduled_post or run_due_posts, and it doesn't clarify how it relates to the other list_* 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?

No when-to-use guidance, no prerequisites, no named alternatives. It does not say whether calling it without a filter returns everything or only upcoming posts, nor when an agent should prefer this over run_due_posts or cancel_scheduled_post.

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

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

Annotations only declare write/open-world/non-destructive; the description adds the crucial behavior that calls are preview-only by default and that confirmation is a two-step human-approval gate. It also discloses dual-provider routing, which the annotations do not.

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

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

Two tight sentences with no filler; the preview/confirm safety gate is front-loaded and the provider routing is stated compactly. Every clause carries information.

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

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

For a 6-parameter write tool with no output schema and no parameter descriptions, the description covers the safety gate, the return-shape caveat (preview), and routing. Remaining gaps are chatId formatting and attachment field dependencies, which an agent may 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 coverage is 0%, so the description must carry the load. It explains confirm and the green/cloud provider enum meaningfully, and gestures at fileUrl via 'image/file URL', but chatId format (phone vs group id) and the fileName/fileUrl relationship are never clarified.

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 message to a group/chat) and disambiguates the two delivery paths: Green API for groups/chats versus WhatsApp Cloud API for individuals. An agent can distinguish it from draft_post and schedule_post without opening any schema.

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

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

Gives an explicit conditional flow: without confirm:true it only previews, and confirm:true should only be set after the user explicitly approves the exact text and destination. It does not, however, say when to choose this over draft_post or schedule_post, which are the nearest siblings.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description goes further by warning that returned content is untrusted user text and must be treated as data, which is genuinely valuable behavioral context for an agent processing group chat. It omits ordering, default/max message count, and rate-limit behavior.

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

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

Two sentences, no waste, and the core action is front-loaded before the safety caveat. Both sentences earn their 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?

There is no output schema, so the description should ideally indicate what a returned message looks like or how many are returned by default. The untrusted-content warning is a strong addition, but parameter and return-shape gaps keep it only adequate for a two-parameter 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 description coverage is 0% for both parameters, so the description carries the full burden. It never explains the groupId format or that 'count' selects the number of messages returned (bounded 1-200 in the schema). Only the phrase 'most recent' hints at count semantics.

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

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

States a specific verb and resource with scope: 'Read the most recent messages of a group,' and even names the backing API call (getChatHistory). It is clearly distinguishable from siblings like list_groups or group_info, though it does not explicitly name them.

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

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

There is no when-to-use or when-not-to-use guidance and no alternative named among the ten siblings. 'Most recent messages' implies the context of reading a group's history, but the agent must infer that on its own.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, but say nothing about the two-mode behavior. The description adds the critical fact that omitting confirm yields a preview rather than a send, which is real value beyond the structured data. It omits idempotency/re-run behavior and failure handling, keeping it from a 5.

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

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

Three short sentences, front-loaded with the action, then the mode switch, then the intended caller. No filler and nothing 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 and sparse annotations, the description covers the operation, its two modes, and its intended trigger. It leaves out return shape for the preview mode and re-run/idempotency semantics, which are relevant for a cron-driven sender.

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% and the confirm boolean has no schema description, so the description must carry the meaning — and it does, fully specifying that confirm:true sends while its absence previews. Only the parameter's exact naming/typing detail is left to the schema.

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

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

Specific verb+resource with a scoping qualifier ('scheduled posts whose time has come') that separates it from post_message, schedule_post, and list_scheduled_posts. An agent can identify the exact operation without opening the schema.

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

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

Gives clear context for when to use it ('Intended for a cron job the user set up') and explains the dry-run vs live distinction. It does not name sibling alternatives or state when NOT to use it, so it falls short of a 5.

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

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

Annotations declare a non-read, non-destructive, open-world write; the description adds genuinely new behavioral facts beyond that — the confirm:true dry-run/preview mode, and that nothing is sent until an external trigger (run_due_posts from cron) fires. It omits permission/auth requirements and any rate limits, so not a full 5.

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

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

Three short sentences, zero filler, and the highest-value constraint (the confirm preview behavior) is front-loaded immediately after the purpose.

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

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

Covers the confirm workflow and the cron dependency, which are the two facts an agent must know to use this correctly. With no output schema and no parameter descriptions, it could still say what the preview returns and what provider/sendAt mean, so it falls short of 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 0% across 5 parameters, so the description carries the load and it only explains confirm's semantics. chatId, text, the date-time format of sendAt, and the green/cloud provider enum are left entirely to the bare schema.

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

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

States a specific verb and resource with scope: "Queue a post for a future time." An agent can tell this is deferred delivery, distinct from the immediate-send siblings. It does not explicitly name post_message or draft_post as the non-scheduling alternatives, so sibling differentiation is only partial.

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 operating context: omit confirm to get a preview, pass confirm:true to actually queue, and run_due_posts (with confirm) is what delivers them. However it never says when to prefer this over draft_post or post_message, so the alternatives guidance is incomplete.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds a genuinely useful behavioral note ('Deterministic stats; the assistant can write prose on top'), clarifying that output is reproducible and that prose generation is the caller's job. However, it never defines the window that 'recent messages' covers, which materially affects behavior.

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

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

Two dense sentences, front-loaded with the core purpose, then the output inventory, then the determinism/prose caveat. No filler and nothing repeated from the schema or annotations.

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

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

With no output schema, the description usefully substitutes by listing the digest's contents, and the annotations cover safety. The remaining gaps are the undefined 'recent' time window and the unspecified default/interpretation of 'count', which an agent would need to resolve 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% and the description mentions none of the three parameters. 'count' (bounded 10-500) has an unspecified default and an ambiguous meaning (message count vs. digest length), and 'timezone' is never explained relative to 'busiest hours' — a real semantic gap for a tool whose headline output is a time-of-day distribution.

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 ('Activity digest for a group from its recent messages') and immediately enumerates the dimensions of the digest: volume, active members, busiest hours, keywords, unanswered questions, shared links. This is clearly distinguishable from the raw sibling read_group_messages, since it is an aggregate rather than a message fetch.

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 explicit when-to-use or when-not guidance and no sibling is named. The phrase 'from its recent messages' implies it is a downstream/analysis tool rather than a raw read, but the agent must infer that read_group_messages is the alternative when raw messages are wanted.

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