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

With no annotations, the description carries the full burden and delivers real behavioral detail: phone numbers must be international format and 'JID form (12345@c.us) is rejected here', variables become `{key}` template tokens, custom tokens override built-ins, and four built-in tokens always resolve. These are non-obvious runtime semantics an agent could not infer. It is silent, though, on what delete does to stored contacts, permissions, and pagination 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?

The structure is front-loaded and scannable: purpose sentence, action list, then constraint notes, then examples. Nothing is redundant, though the examples slightly restate what the action list already conveys.

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 9-parameter, 8-action tool with no annotations and no output schema, the description covers the hardest semantics (token variables, phone validation) but omits pagination parameters, how `contact_id`/`audience_id` are obtained, and the consequences of delete. An agent can call the main flows correctly but would guess on the rest.

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 must compensate and does so for several: `to` format, `variables` substitution semantics, `name` on create, and the nested contacts shape ('to + optional variables'). It leaves `skip`, `limit` (pagination), `contact_id`, and `audience_id` entirely unexplained, so roughly half the parameters remain undocumented 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?

The opening line names the resource and its role ('Reusable contact lists used as targets for messages and campaigns'), and the action list gives a concrete verb inventory. An agent knows exactly what domain this covers, though it doesn't distinguish the tool from siblings like contacts or campaigns.

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?

Enumerating actions with one-line glosses ('list audiences', 'create a new audience by name') tells an agent which action to pick, and the examples illustrate two common flows. However, there is no guidance on when to use this tool versus contacts or campaigns, and no prerequisites or exclusions are 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 real traits: paced delivery, pause/resume/cancel control, and the important default that on_missing_variable=fail rejects at create time while skip leaves the literal `{token}` in the send. It is silent on permissions, whether cancel affects already-queued messages, and idempotency of create, which matter for a bulk-send mutation.

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

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

Front-loaded with the action list, then template semantics, then examples — a sensible order for a multi-action tool, and the per-action bullets are terse. The token-resolution paragraph is dense but every sentence carries information an agent needs to compose a valid `text` value.

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 10-parameter, six-action tool with no annotations and no output schema, the definition covers the create path well and the control actions adequately. It still leaves `skip`/`limit` unexplained and gives no sense of what list or get returns, so an agent cannot fully plan a listing flow from the description alone.

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 largely does: name, audience_id, text, media_url, media_caption, campaign_id, and on_missing_variable are all given meaning, including the non-obvious fail/skip trade-off. The two pagination-ish parameters `skip` and `limit` are never mentioned, leaving the compensation incomplete.

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 opens with a specific verb and resource — scheduling audiences for paced bulk delivery — and enumerates all six actions with one-line definitions, so an agent knows exactly what surface it covers. It does not differentiate itself from the sibling `scheduled_messages` or `audiences` tools, which is the only thing keeping it from 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?

Each action is described with enough context to pick the right one (create needs name + audience_id, pause/resume/cancel operate on a campaign_id), and two worked examples show realistic invocations. However there is no guidance on when to use this tool versus `scheduled_messages`, no prerequisites, and no statement of what cannot be done here.

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 full behavioral burden and does so well for the most complex action: it discloses `load_more_history` pacing, `added:0` retry semantics, `not_connected` during initial sync, `cooling_down:` errors, and `canLoadMore:false` exhaustion. It also notes that sends are fire-and-forget, archive/unarchive hide or restore a chat, and `get_media` may return a preview via `original_quality=false`. It still omits some operational details such as send failure modes, permission requirements, and rate limits for sending media.

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 long, but the length is largely justified by 13 actions and several important caveats. It is front-loaded with the core purpose and structured as a clear bullet list with examples at the end. The `load_more_history` section is somewhat verbose and repetitive, but most sentences provide operational value rather than 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?

Given the tool's complexity, lack of annotations, and 0% schema description coverage, the description is substantially complete for action selection and many invocation details, especially for `load_more_history` and immediate versus scheduled sending. It still leaves some optional parameters and return-shape expectations undocumented, so an agent may need to infer how to use filters such as `since`, `until`, `message_types`, and `reply_to` correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it does explain several important parameters: `limit`/`skip` pagination, `query` in search, `include_archive`, `chat_id` examples, poll option constraints, media body fields, and automatic `type` derivation for send actions. However, several parameters remain unexplained, including `key`, `order`, `since`, `until`, `message_types`, `reply_to`, and `media.data_base64`, leaving meaningful gaps across a 16-parameter 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?

The description opens with a specific verb and resource: "Read or send WhatsApp messages inside chats on the connected engine." It then enumerates all 13 actions with concrete meanings, so an agent can distinguish chat listing, searching, message listing, media retrieval, and sending without opening the schema. It also explicitly separates immediate sends from the sibling `scheduled_messages` tool.

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 gives explicit usage conditions: `send_message_*` is for immediate delivery while `scheduled_messages` handles future sends, `include_archive=true` is needed to find archived chats, and `load_more_history` is the tool to use when a chat's loaded messages do not reach far enough back. These are concrete when-to-use and when-to-use-alternative instructions rather than implied 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?

With no annotations, the description carries the full burden; it does disclose that this is a read operation and that list uses offset pagination via limit/skip, which is genuine behavioral context. It does not cover permissions/authorization nuances (e.g., whether common_groups works for contacts not in the address book), rate limits, or what the response contains and whether more pages exist.

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?

Purpose is stated in the first line, followed by a scannable action list and two short examples; each line earns its place. The two example lines are marginally redundant with the action bullets but still aid selection.

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 5-parameter, action-dispatch tool with no annotations and no output schema, the description covers inputs and actions but says nothing about return values or how paginated results signal completion. The per-action coupling of parameters (e.g., chat_id only for common_groups) is implied by the bullets but not stated explicitly.

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 define the parameters, and it largely does: query is the filter for list, limit/skip implement offset pagination, and chat_id is the contact JID with a concrete example format (12345@c.us). The action enum is explained action-by-action; only the limit ceiling (200) 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?

The description opens with a specific verb+resource ("Read WhatsApp contacts known to the connected engine") and enumerates the two supported actions (list, common_groups) with their semantics. It never names a sibling (chats, groups) as the alternative for contact-adjacent needs, so differentiation from siblings is only implicit.

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 per-action examples ("find contacts named Douglas", "what groups do I share with...") show how each action is intended to be used, which is real guidance for picking the right action. However, there is no explicit when-not guidance or routing to sibling tools such as groups or chats, so an agent must infer the boundary.

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 load — and it does disclose the important behavioral detail that an empty array means no engine connected rather than an error, plus the per-entry field set ({id, type, connected, state, stream, hasSynced}). It omits auth/permission requirements and the meaning of fields like state and stream.

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

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

Front-loaded purpose followed by action and return semantics, with no filler. The "Available actions" heading and an example for a single-action tool are slightly over-structured for what is essentially one call, but not 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?

For a one-parameter, single-action read tool with no output schema, the description supplies everything needed: the action, the return array shape, and the empty-array non-error case. Nothing material for correct invocation is missing.

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

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

Schema coverage is 0%, but the single parameter is a one-value enum ("status") that is self-documenting; the description nonetheless explains what that action does and what it returns. Minor gap: no note that the enum is currently limited to a single action.

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: "Inspect the WhatsApp engine(s) connected to this account." No sibling (chats, contacts, groups, campaigns, webhooks, etc.) overlaps with connection/engine status, so an agent can route to it unambiguously.

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 example framing ("is WhatsApp connected?") implies the use case, but there is no explicit when-to-use or when-not-to-use statement, nor a named alternative. With only one action available, the guidance burden is low, so implied usage is adequate but not strong.

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 does so well: it discloses that create defaults to announce=true/restrict=true, that leave only ends your membership while the group survives, that participant_count includes the creator, and that self-invites dedupe into the owner slot. It omits permission/auth requirements (e.g., that update/leave may require admin rights) and any error or rate-limit behavior, so it is rich but not complete.

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

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

Front-loaded with the action list, then notes, then examples — a clean hierarchy that lets an agent stop reading once it has what it needs. The examples largely restate the action bullets, so a bit of the content is redundant rather than additive.

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 5-action, 9-parameter dispatch tool with a nested settings object and no annotations or output schema, the description covers action semantics, defaults, edge cases, and one return-shape detail (create returns participants[] inline). An agent has enough to select and invoke any action correctly, with only minor uncertainty about list/get response 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?

Schema description coverage is 0%, so the description must compensate, and it defines most of the 9 parameters: group_id with a concrete format example, participants as phone numbers, include_participants as inline member list, settings.announce/restrict with their meaning, query as an optional name filter, and skip/limit as offset pagination. The bounds (limit max 200, minimums) and the exact skip/limit parameter names are not surfaced, leaving a small 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 domain (WhatsApp groups) and enumerates all five actions (list/get/create/update/leave) with the verb+resource for each, so an agent knows exactly what capability set is behind this tool. It also distinguishes the resource from sibling tools like chats and contacts by scoping everything to groups.

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

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

The 'Available actions' list plus the natural-language examples ('show me my groups', 'leave group g@g.us') give clear when-to-use routing for each action, and the 'leave' note explicitly says WhatsApp has no destroy-group, which prevents the wrong choice. It never contrasts itself with sibling tools (e.g., when to use groups vs chats for member info), 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?

With no annotations, the description carries the full burden and does well: it discloses that edits/cancels fail once dispatched, that `waMessageKey` is null until the engine dispatches and must be re-fetched via `get`, that `ack` is batched up to 200 keys, and that `list` returns newest-first. It stops short of permissions/auth requirements, error semantics, or rate limits, which is why it isn't 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?

The action list, identifier-model block, and examples are clearly sectioned and front-loaded, so an agent can scan to the relevant action quickly. It is long, and some example lines restate guidance already given above, but the length is largely justified for six actions across thirteen parameters.

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 six-action tool with thirteen parameters, no annotations, and no output schema, the description covers the load-bearing pieces: the id/waMessageKey chaining model, pagination, status filtering, and mutation preconditions. Return shapes are only loosely characterized (no output schema exists to defer to), and the `to` field remains underspecified, so it falls slightly short of fully self-sufficient.

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, and it largely does: it explains `text`/`media_url`/`media_caption`/`poll` mutual exclusivity, `send_at` for scheduling, `limit`/`skip` as offset pagination, `chat_id` as a recipient JID filter, and the `id` vs `waMessageKey` split with its `_serialized` form. Gaps remain — the required `to` parameter is never defined (only hinted at through an ambiguous example string) and `skip` is implied rather than stated.

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 opens with an explicit verb list (send, list, edit, cancel, look up status) tied to the WhatsApp message resource, then enumerates each of the six actions the single `action` enum supports. This makes it immediately distinguishable from siblings like `chats`, `contacts`, or `campaigns`, which deal with different resources.

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

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

It gives explicit selection rules per action and real exclusions: `update`/`cancel` only apply to pending messages that haven't dispatched, `status: 'pending'` is the way to see queued messages, and the three payload forms (text / media_url / poll) are declared mutually exclusive. The natural-language examples map directly onto each action, leaving little inference for an agent.

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 and discloses useful traits: no backend call is required, the result is local, and the timezone reflects the MCP host rather than the caller. It does not explicitly state read-only safety, but the operation is inherently a read.

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 short, front-loads the key constraint, and uses a compact action list plus one example. Every sentence adds useful information without unnecessary repetition.

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

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

For a one-action utility with no output schema and no annotations, the description covers purpose, usage, and host-timezone semantics well. It stops short of specifying the exact return format or timezone string format, which would fully close the gap.

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%, but the sole parameter is a single-value enum and the description explains the meaning of that action, including what it returns. More detail on the returned date/time format could improve it, but the parameter is otherwise fully understandable.

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 identifies the tool as a set of local helpers that avoid a backend call and specifically explains the only available action, current_date_time. It is clear what the tool does, though the broad namespace name 'utils' is only disambiguated by the description.

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

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

It gives an explicit usage rule: call this before any tool that takes a future timestamp. The example also shows the intended natural-language trigger, leaving little ambiguity about when to invoke it.

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 full burden. It does add genuine behavioral context: deliveries are HTTPS POSTs triggered by named events such as message.delivered. But it is silent on authentication/secret verification, retry and failure behavior, whether delete is irreversible, and what the create/get responses contain for a tool that also supports mutation and deletion.

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 one-line purpose is front-loaded, followed by a compact action list and a single concrete example. The `get / update / delete: standard CRUD` line is slightly redundant but earns its place by covering three actions in one clause. No filler sentences.

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 7-parameter tool with no annotations and no output schema, the description covers the essential what-and-which-action but omits auth requirements, deletion consequences, pagination, and return shape. Adequate for selecting the tool, thin for invoking it safely.

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 7 parameters, so the description must compensate. It meaningfully explains `url` and `events` through the create example and gives the `action` enum values verbatim, but `skip`, `limit`, `status`, and `webhook_id` are never mentioned, leaving pagination and enable/disable semantics 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 resource and effect: registering URLs to receive HTTPS POSTs on Blueticks events. It then enumerates the five supported actions, so an agent immediately knows this is a multi-action webhook CRUD tool. It does not explicitly contrast itself with siblings, but the resource is distinct enough from chats, campaigns, and audiences that confusion is unlikely.

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 action list implicitly routes an agent to the correct sub-operation, and the create example shows the shape of a registration request. However, there is no guidance on when a webhook is the right tool versus polling or the other sibling resources, and no prerequisites such as required scopes or signing-secret setup.

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