Wapiworld WhatsApp API

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety and repeatability are covered. The description adds genuine context beyond them by enumerating the returned fields and disclosing the 'not-found' outcome for a missing instance.

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, zero filler, and the usage trigger is front-loaded ahead of the return-value list and the exclusion. Every clause carries information an agent needs.

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

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

With a rich annotation set and an output schema present, the description needn't restate return values, and it correctly focuses on when to call it plus the not-found case. The only remaining gap is the unresolved overlap with get_instance_status.

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

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

Schema description coverage is 100% and the single instanceId parameter is fully documented in the schema (24 lowercase hex characters, with a regex pattern). The description adds no syntax or format information beyond it, so the baseline of 3 applies.

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

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

Specific verb+resource: 'one connected WhatsApp number' with the fields it exposes (phone number, account name, connection health). It implicitly separates itself from list_instances by scoping to a single instance. However, it never addresses the near-duplicate sibling get_instance_status, which appears to overlap with the 'status and health' it claims to return.

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 this when someone asks about one connected WhatsApp number' gives a clear trigger condition, and 'Not for message history, which this connector does not read' is an explicit exclusion. What's missing is disambiguation against get_instance_status, the one sibling most likely to be confused with 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuine value beyond that: it lists the returned health vocabulary and clarifies the tool returns no QR codes or credentials, which sets expectations about output. It does not discuss rate limits or error behavior, so it falls just short of 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?

Two sentences, front-loaded with the trigger condition, and every clause earns its place by either scoping usage or enumerating the return vocabulary. 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-value documentation is not strictly required, yet the description still names the health states. Combined with annotations covering safety, the definition gives an agent everything needed to select and call the tool 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 coverage is 100% and the single instanceId parameter is fully documented in the schema (24 lowercase hex chars), so the description adds no parameter semantics beyond what structured data provides. Baseline 3 applies.

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

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

States a specific verb and resource ('check whether a WhatsApp number is connected') and enumerates the distinct states it detects (ready, pairing, starting, offline). It also explicitly distinguishes itself from the adjacent concern of message delivery, which is the main sibling confusion for a status 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?

Opens with an explicit trigger ('Use this when someone asks whether a WhatsApp number is connected...') and closes with an explicit exclusion ('Not for whether a sent message was delivered'). Both the when and the when-not are stated, leaving nothing to inference.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description's added content is mostly a restatement of return fields, which the output schema already supplies, rather than new behavioral context like auth requirements or error conditions.

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 sentences, front-loaded with the user-facing trigger, with zero filler. The middle sentence listing return fields is partly redundant given the output schema exists, which keeps it from a 5.

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

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

For a single-parameter read tool with full annotation coverage and an output schema, the description covers what it does, when to call it, and what not to use it for. It could be slightly stronger by pointing to the sibling tool an agent should use for the excluded case, but nothing essential 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?

There is a single parameter, instanceId, with 100% schema description coverage including a format pattern, so the schema does the heavy lifting. The description never mentions the parameter or its identifier format, adding no meaning beyond the schema — the baseline for fully covered parameters.

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 names a specific resource (WhatsApp message text recording policy for a number) and verb (check), and enumerates exactly what is returned: whether recording is on, which level decided it, any lock, and project retention days. It is clearly distinguishable from all siblings such as get_instance, get_instance_status, and list_webhook_subscriptions.

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 trigger ('use this when someone asks whether Wapiworld stores the text of WhatsApp messages...or how long it keeps them') plus an exclusion ('Not for reading recorded messages'). It stops short of naming the alternative tool to use instead for reading messages, so routing is partly left to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds genuinely new context: default page size of 25, optional project scoping, and an explicit note that QR codes, secrets and API keys are excluded from the payload. It does not mention auth/permission requirements, which keeps it below 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?

One dense, front-loaded sentence that leads with the use case and ends with the exclusion. It is efficient with no filler, though the return-field enumeration makes the sentence long and slightly harder to scan.

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 annotations covering the safety profile and an output schema covering return shape, the remaining needs are trigger conditions, pagination behavior and sensitive-field exclusions — all present. Nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, so limit, cursor and projectId are fully documented in the schema itself. The description only echoes the 25-per-page default and project scoping, adding no syntax or format detail beyond the schema — the baseline 3 for high coverage.

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

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

States a specific verb and resource ('list instances' / WhatsApp numbers) and enumerates exactly what comes back (id, name, account name, phone, connection status and health). It also rules out the neighboring operation with 'Not for sending a message', so an agent can separate it from send_message and get_instance without opening a 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 trigger ('when someone asks which WhatsApp numbers they have connected... or which ones are offline') plus one exclusion ('Not for sending a message'). It stops short of naming the single-instance sibling (get_instance) as the alternative when the user asks about one number, which is the most likely adjacent intent.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: default page size of 25 and cursor-based continuation for more results, which the annotations do not express.

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

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

Three short sentences, each earning its place: trigger condition first, output/pagination second, exclusion last. No filler and nothing buried.

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

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

An output schema exists, so return values need not be spelled out, yet the description still names the returned fields and pagination model. Trigger, scope, page size, continuation and exclusion together give an agent everything needed to invoke it correctly.

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

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

Schema coverage is 100% and both parameters are fully documented in the schema, including the 1-100 range and cursor provenance. The description restates the default page size and cursor but adds no syntax or semantics beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('list ... Wapiworld projects') and explicitly delimits scope with 'Not for their WhatsApp numbers', which separates it from list_instances and related siblings without needing their schemas.

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 trigger conditions ('when someone asks which projects they have, or a project's id is needed') and one explicit exclusion (WhatsApp numbers). It stops short of naming the sibling tool an agent should use instead for that excluded case, so routing is clear but not fully closed.

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 read-only/idempotent/non-destructive, and the description adds behavior beyond them: the 20-consecutive-failure auto-disable rule, the 25-per-page default, and the operator-OAuth-only auth requirement. These are concrete operational facts an agent could not derive from the annotations.

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 front-loaded sentences: trigger, return shape, constraints. Efficient overall, though enumerating returned fields (endpoint, events, active state, failures) is partly redundant given an output schema exists.

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 read-only paginated list tool, the description covers trigger, auth mode, pagination, and the notable auto-disable behavior, and an output schema handles return values. An agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents limit, cursor and projectId thoroughly. The description only restates the page-size default and says nothing about cursor chaining or project scoping, so it adds no meaning beyond the schema; baseline 3 applies.

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

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

The description names a specific resource (webhook subscriptions) and its purpose (checking delivery health), and explicitly bounds it with 'Not for changing a webhook'. An agent can tell this apart from the instance/project/message siblings without opening a 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?

It gives an explicit trigger ('when someone asks whether their webhooks are working, failing or were switched off'), a prerequisite ('only with an operator OAuth session, not an API key'), and an exclusion ('Not for changing a webhook'). Nothing about when to pick this tool is left to inference.

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 flag destructive=true, idempotent=false and openWorld=true, but the description adds context annotations cannot: the result only proves Wapiworld accepted the send, not delivery; the message goes out immediately; each call sends another copy; and recording settings may retain the text. That is exactly the extra behavioral layer the lower bar asks for.

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?

Roughly three sentences, front-loaded with the usage trigger, then the delivery/repeat/recording caveats, then the exclusion. Every clause carries information an agent needs; 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?

An output schema exists, so return-value structure needn't be restated, yet the description still clarifies what the return does and does not guarantee. Combined with full schema coverage and annotations, an agent has everything needed to call this correctly.

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

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

Schema description coverage is 100%, so chatId, content and instanceId are already fully documented with formats, limits and confirmation guidance. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

States a precise verb+resource (send a WhatsApp message) and scopes it to the user's own Wapiworld numbers. Among a sibling set that is entirely read-only (get_instance, list_instances, show_project_overview, etc.), this is unambiguously the one outbound-write tool, so no sibling confusion is possible.

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 this when someone asks to send a WhatsApp message from one of their Wapiworld numbers' gives an explicit trigger condition, and 'Not for broadcasts or bulk sends' gives an explicit exclusion. Both when-to-use and when-not-to-use are stated without inference.

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, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds genuinely useful behavioral context beyond them: the status counts cap at 100 and only up to 20 instances are returned, which tells the agent results may be truncated. It does not mention permissions or error behavior, but those are minor for a read-only dashboard.

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 usage trigger, then the return shape, then the exclusion. Every sentence carries distinct information with no repetition or 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?

For a single-parameter read-only tool with an output schema and full annotation coverage, the definition supplies the usage trigger, the return shape, the truncation limits, and an exclusion. Nothing an agent needs in order to call this correctly is missing.

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

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

Schema description coverage is 100% and there is only one required parameter, projectId, so the schema carries the burden. The description adds no format, ID-source, or lookup guidance beyond what the schema already states, so the baseline 3 applies.

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

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

States a concrete verb and resource ('quick overview or dashboard of one Wapiworld project's WhatsApp numbers') and enumerates the card contents, so the agent knows exactly what comes back. It partially differentiates from siblings via the 'one project' scope and the explicit 'Not for sending a message', but never contrasts itself with list_instances or list_projects, which return overlapping data at a different granularity.

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 this when someone wants a quick overview or dashboard' gives a clear triggering intent, and 'Not for sending a message' supplies one exclusion. However, the real ambiguity for this tool is overview-vs-list (list_instances, list_projects) and that boundary is left unaddressed.

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