Wapiworld WhatsApp API

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful beyond-annotation context by explicitly listing what is never returned (QR codes, secrets, API keys, proxy addresses, org ids, stored metadata), which helps the agent understand the tool's safety boundary and not expect sensitive fields.

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 with no redundancy. The first sentence front-loads the core purpose, and the second adds a valuable boundary without padding. Every phrase earns its 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?

Given only one parameter, a complete output schema, and safety-relevant annotations, the description covers the critical behavioral and scope information. It misses nothing essential for correct invocation; the output schema handles return-value details, so the description's exclusion list is the main added 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 coverage for the single parameter is 100% and the schema already defines the instanceId format and meaning. The description adds only the 'tenant-scoped' qualifier, which is mild context but does not materially change how the parameter should be set. Baseline 3 is appropriate because the schema carries the parameter 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?

The description uses a specific verb ('Fetch') with a clear resource ('one tenant-scoped Wapiworld WhatsApp instance') and scope ('safe operational details'). It distinguishes itself from list-oriented siblings like list_instances by emphasizing a single instance, and from get_instance_status by focusing on operational details rather than status.

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 clearly states when to use the tool: to fetch safe operational details for a single instance. It does not explicitly name alternatives or when-not-to-use conditions, but the single-instance scope and safe-details wording provide enough context for an agent to distinguish it from list_instances and get_instance_status.

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 establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral context by promising a 'current' health snapshot and explicitly excluding sensitive pairing/authentication data. It does not discuss errors or permissions, but the output schema covers return shape.

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 tightly written sentence front-loads the action and resource, then adds the key exclusion. No filler or 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 single-parameter, read-only tool with rich annotations and an output schema, the description is complete. It covers scope, freshness, and data exclusions, leaving no significant gap 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 coverage is 100%: instanceId is fully described with type, pattern, and meaning. The description adds no parameter-level detail beyond 'one tenant-scoped instance,' so it meets the baseline but does not exceed it.

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 verb ('Fetch'), resource ('safe connection health'), and scope ('one tenant-scoped Wapiworld instance'). It also states what the tool intentionally excludes (QR pairing codes or authentication data), which distinguishes it from related instance tools such as get_instance.

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 clear context: this is for checking current health of a single instance, not for retrieving pairing or auth material. It does not explicitly name sibling alternatives or state when not to use it, so it falls short of 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?

The description goes beyond the readOnlyHint and idempotentHint annotations by explicitly guaranteeing what the tool does not read: message bodies, previews, sender names, contact identifiers, chat-level override keys, and WhatsApp message ids. This is a strong privacy-focused behavioral disclosure that materially helps an agent judge safety and scope.

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 compact sentences carry all the essential information: the first states the purpose and scope, the second adds the critical privacy guarantee. There is no filler, repetition, or unnecessary detail.

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 one well-documented parameter, an output schema available, and annotations covering read-only, idempotent, and non-destructive behavior, the description covers everything needed to invoke the tool correctly. It even clarifies the sensitive data it avoids, so no critical behavioral information 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?

The input schema already fully documents instanceId with type, pattern, and meaning, so the description adds no new parameter-level information. Since schema description coverage is 100%, the baseline of 3 applies; the description's mention of 'tenant-scoped Wapiworld instance' aligns with but does not enrich 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 names the exact resource (message recording policy), the action (inspect), and the scope (one tenant-scoped Wapiworld instance), while also stating what it determines: default persistence and retention length. This clearly differentiates it from sibling tools like get_instance or list_instances by focusing on the recording policy specifically.

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 imperative 'Inspect whether...' effectively frames when to call the tool: when you need message-content persistence and retention settings for a single instance. It does not explicitly list alternatives or conditions to avoid using it, but the resource is specific enough that the intended use case is clear without 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?

Beyond the annotations (read-only, idempotent, non-destructive), the description explicitly discloses what results include and exclude — operational status and phone metadata but never secrets, QR codes, API keys, or arbitrary fields. This is valuable context not present in 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?

A single well-structured sentence front-loads the action and resource, then adds the filter and result scope. Every clause adds information, with no filler or redundancy.

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 format is handled elsewhere. The description covers scope, filtering, and exclusions, which is sufficient for a list operation. It could have mentioned that pagination uses cursor/limit, but those are already described in the schema.

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 all three parameters. The description adds minimal value here, only reinforcing the project filtering concept already present in the projectId schema 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 description uses a specific verb ('List') and a specific resource ('tenant-scoped Wapiworld WhatsApp instances'), and adds scoping details (bounded page, optional project filter). It clearly distinguishes itself from singular siblings like get_instance and get_instance_status.

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 states the operation's scope and the optional project filter, giving clear context for when to call it. However, it does not explicitly contrast with alternatives such as get_instance for a single instance or get_instance_status for status-only retrieval.

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 destructiveHint=false, so the description's job is to add context. It does so by specifying that results are a bounded page, that internal org ids and project configuration are omitted, and that API-key sessions are pinned. These are meaningful behavioral disclosures beyond 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?

Two concise sentences, each earning its place: the first states the core action and scope, the second adds two crucial behavioral notes (pinning and omissions). No fluff or redundancy.

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 are covered elsewhere. The description covers the essential context: what is listed, for whom, and what is deliberately omitted. Combined with annotations and schema, an agent has everything needed to call 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% with both parameters (limit and cursor) fully described in the schema. The description adds no additional parameter-level detail, so the baseline of 3 is appropriate because the schema carries the full burden.

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 clear verb (List) and resource (projects) and defines the scope (bounded page for the authenticated organization). It does not explicitly differentiate from sibling tools like list_instances or show_project_overview, so it misses the top score but is still 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 implies usage context by noting that API-key sessions remain pinned to a single project, suggesting this tool may be limited for such sessions. However, it does not explicitly state when to use this tool instead of alternatives or provide exclusion criteria, so guidance is implied rather than explicit.

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?

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description reveals important behavioral details: the signing secret is never returned, and only the scheme and host of the delivery URL are shown because hook paths may embed credentials. It also discloses the auto-disable rule (20 consecutive failures). These add significant context beyond the annotations, enhancing transparency.

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 four sentences, each earning its place. It front-loads the purpose, then provides operational context (auto-disable, auth, and security details). There is no fluff or redundancy, making it concise yet information-dense.

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 output schema present, the description need not explain return values. It covers the key aspects: what the tool lists, why it's used, auth constraints, security behavior, and pagination implications ('bounded page'). It could have explicitly mentioned how to paginate with cursor, but the schema already describes that. Overall, it is sufficiently complete 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%, with each parameter (limit, cursor, projectId) having a clear description. The tool description does not add extra parameter-specific meaning, but given the high schema coverage, a baseline of 3 is appropriate. The description's mention of 'bounded page' aligns with limit and cursor semantics but doesn't introduce new information.

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 clearly states the action ('List a bounded page') and the specific resource ('Wapiworld webhook subscriptions'), with the diagnostic purpose ('so a stopped webhook can be diagnosed'). It distinguishes itself from siblings like list_instances and list_projects by focusing on webhook subscriptions, making the tool's role 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 provides clear usage context: it is for diagnosing stopped webhooks, mentions the auto-disable behavior, and explicitly states the authentication requirement (operator OAuth session, API-key sessions cannot read). While it doesn't name alternative tools, the context is sufficient for an agent to decide when to use this tool over 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 destructive, open-world, and non-idempotent behavior, and the description adds valuable operational safeguards: show exact sender/recipient/text, obtain explicit confirmation, call once, never auto-retry on uncertain outcomes, avoid restricted data, and note that recording settings may persist content. This meaningfully exceeds what annotations alone provide.

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 compact and front-loaded: the first sentence states purpose, then the following sentences deliver the safety protocol without redundancy. Every sentence adds meaningful guidance for correct invocation.

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 three-parameter tool with 100% schema coverage, output schema, and strong annotations, the description is complete. It covers the action's purpose, safety workflow, restricted-data constraints, and behavioral side effects, giving an agent everything needed to call 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 input schema fully documents all three parameters. The description contributes safety-oriented guidance about showing sender, recipient, and text before sending, but does not add new parameter-level semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

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 ('send') and resource ('real external WhatsApp text message through a tenant-scoped Wapiworld instance'). It clearly distinguishes this as the only messaging tool among the sibling tools, which are all read/status/list operations.

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 clearly establishes the action's context and safety expectations, and no competing send tool exists among the siblings. It does not explicitly name alternatives or exclusions, but the 'clear context, no exclusions' level fits because the sibling set is all non-send operations.

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 indicate read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond that by specifying the exact scope of returned data and explicitly excluding sensitive fields like QR pairing codes, credentials, API keys, and proxy data. This helps agents understand the bounded nature of the operation.

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

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

The description is a single, tightly written sentence that front-loads the core purpose, names inclusions, and lists exclusions. Every clause earns its place with no redundant or filler content.

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 tool with one documented parameter, a rich annotation set, and an output schema, the description is complete enough. It tells the agent what the tool returns, what it deliberately omits, and the project scope, leaving no critical gaps.

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

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

Schema description coverage is 100%, and the single parameter projectId is already described in the schema as 'Wapiworld project id to summarize'. The description adds only the tenant-scoped qualifier, which is useful but not a substantial improvement over 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 uses a specific verb ('Render') and clearly identifies the resource ('a bounded operational overview for one tenant-scoped Wapiworld project'). It also states what is included ('WhatsApp instance health and safe phone metadata') and what is excluded, making it easy to distinguish from sibling tools like get_instance, list_projects, and get_instance_status.

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 'bounded operational overview' and the explicit exclusions provide useful context for when this tool is appropriate, particularly for safe, non-sensitive project summaries. However, it does not explicitly name alternative tools or state when not to use it, leaving some inference to the agent.

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