WALoops

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses substantive behavior: it is a mutation that only creates an OFF draft, it requires an Advance plan key, it auto-names with a prefix, and nothing is sent until the owner turns it on. The 'Tell the user this' instruction is a useful communication constraint. It does not cover error/failure behavior or return shape, keeping it at a 4.

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?

Four sentences, front-loaded with the plan prerequisite then the draft semantics and the send-safety guarantee. Each sentence carries information; nothing is padded. Minor deduction only because 'Tell the user this' is loose prose rather than precise instruction.

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

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

For an 18-parameter creation tool with nested objects, no output schema, and low schema coverage, the description only explains lifecycle state and a plan gate. An agent still has little guidance on how to construct the required/optional inputs or what to expect on success, so completeness is inadequate relative to the tool's 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?

With 18 parameters and only 33% schema description coverage, the schema leaves most inputs undocumented (name, stage, conditions, action_type, schedule fields, etc.). The description adds no parameter-level guidance whatsoever, so it fails to compensate for the coverage gap on a complex nested-object tool.

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

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

The description states a specific verb and resource (creates an automation) plus the critical qualifier that it lands as a DRAFT, saved OFF and auto-named "[AI draft] ...". An agent can tell this is the safe/draft variant rather than something that activates or sends. It stops short of naming a sibling (e.g., pause_automation, list_automations) for direct comparison, so it's clear but not fully differentiated.

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

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

Usage is implied: use this when you want to stage an automation for owner review rather than activate it, and it requires an Advance plan key. There is no explicit statement of when NOT to use it or which sibling to reach for instead (e.g., how this relates to install_recipe_draft or pause_automation), leaving the boundaries 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 only declare this is a non-read-only, non-destructive write; the description adds real value beyond that by disclosing the plan-tier gate, the asynchronous external approval step, and an expected latency window (minutes to a few hours). It omits what happens on rejection or whether the template is callable before approval, 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?

Three short sentences, front-loaded with the blocking prerequisite, then the action, then the follow-up pointer. 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?

The async approval model and plan requirement are covered, which is the main complexity here, but for an 8-parameter tool with nested header/buttons objects, low schema coverage, and no output schema, the description leaves substantial gaps about template composition and the approval result.

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 only 38%, and the description adds nothing about any of the 8 parameters. Undocumented fields like header (with text/format/media_url), buttons (type enum with url/phone_number), footer, category, and language must be inferred entirely from the schema structure.

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 ('Creates a WhatsApp template') plus a distinctive behavioral fact (submission to Meta for approval) that separates it from send_template and list_templates. An agent can identify the 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 a hard precondition ('Requires an Advance plan key') and routes the agent to list_templates for follow-up status checks, which is genuinely useful sequencing guidance. It stops short of saying when not to use it (e.g. use send_template to actually deliver an approved template), but the usage context is clear.

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 already covers the safety profile; the description adds a valuable non-annotation fact — that an Advance plan key is required. It says nothing about pagination behavior or how many messages come back, which matters for a list tool with page/limit params.

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

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

Two short sentences, prerequisite front-loaded, no filler. Efficient, though it is arguably too terse given the undocumented pagination 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?

No output schema, so the description would need to explain return shape, but it does not. Prerequisite and purpose are covered; pagination semantics and result format are missing, leaving it 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 only 33% — the id parameter is documented (with a pointer to list_conversations), but page and limit are bare integers with no description and no explanation in the tool description either. The description does not compensate for the coverage gap.

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

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

Clear verb+resource: "List messages in a conversation." The scope ('in a conversation') implicitly separates it from the sibling list_conversations, but the description never names that sibling or any alternative.

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 plan-key prerequisite is a useful usage constraint, and the schema's id description points back to list_conversations, so the call sequence is implied. However, the description states no when-to-use vs when-not guidance and no alternatives beyond the plan note.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description contributes one genuinely useful behavioral fact beyond the schema: the Advance plan key requirement, which would otherwise cause a failed call. It says nothing about aggregation window, caching, or what 'plan usage' includes.

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

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

Two short sentences with no padding, and the blocking prerequisite is front-loaded where an agent will see it first. The second sentence is a bare fragment rather than a complete clause, which slightly hurts readability but not economy.

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 parameters and no output schema, the description carries the whole burden of explaining the return. It names the four data categories but not the time range, granularity, or shape of the 'overview', which an agent needs to decide whether this answers its question.

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

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

The tool takes zero parameters and the input schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 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 is a noun list — 'Messages, conversations, automations and plan usage overview' — with no verb, so the agent must infer that this returns aggregated dashboard statistics. It does hint at an aggregate rather than a list, which loosely separates it from siblings like list_conversations and list_automations, but that distinction is never made explicit.

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 only guidance is a prerequisite ('Requires an Advance plan key'). There is no statement of when to reach for this aggregate view versus calling list_conversations, list_automations, or get_otp_usage individually, and no 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?

Annotations already declare readOnlyHint=true and the description's 'Read' is consistent with that. The description adds that limits/quota data is surfaced, but says nothing about whether the result is per-key or per-site, how quota windows or resets work, or what happens when the site_url is unknown to the OTP API.

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 short sentence, front-loaded with the verb and resource, with no filler. The trailing 'usage or limits' is slightly loose phrasing but still earns its place by indicating the returned data type.

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 annotations covering safety, the description is close to sufficient, but with no output schema the burden of describing return values falls on the description, and 'available usage or limits' is too vague to tell an agent what fields or units to expect.

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 site_url is already well documented in the schema, including its purpose and format. The description adds no parameter-level information, 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 ('Read OTP usage for the API key') plus the scope of what is returned (available usage or limits), which clearly separates it from the send_otp/verify_otp siblings. It does not explicitly name those siblings, but the read-only framing makes the distinction obvious.

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 explicit 'use this when...' statement or exclusion. The phrase 'including available usage or limits' implies a pre-send quota check, but the agent must infer that this is the tool to call before send_otp rather than being told.

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

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

No annotations are provided, so the description carries the burden. "Explain" signals an informational read operation with no side effects, but it never states that explicitly, nor whether the output is static docs versus live configuration, or whether any auth is required.

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 enumerated topic list is slightly sprawling but every item is a distinct piece of content the tool returns.

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

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

For a zero-parameter, annotation-free documentation tool with no output schema, the topic list is enough for an agent to know what it will get back. Only a note on return format (markdown text vs structured) 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 tool takes zero parameters and the schema is a closed empty object, so there is nothing parameter-level left to document; baseline 4 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 ("Explain") and enumerates the exact content it covers: WALoops setup, key types, tool groups, API docs, and example OTP requests. That clearly separates it from the operational siblings like send_otp or list_automations, though it never explicitly frames itself as the onboarding entry point.

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 name get_started and by the content list — an agent can infer this is the orientation tool to call before send_otp or create_template, but no sentence says when to call it, when not to, or that it should precede other tools.

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=false and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: it discloses a plan-key prerequisite ('Requires an Advance plan key') and states the operation produces a switched-off draft rather than an active recipe, which is important behavioral context for a mutation tool.

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

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

Two short sentences with no waste. The prerequisite and the outcome are front-loaded, so an agent can assess eligibility before reading further.

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

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

The definition covers the key facts an agent needs: plan requirement, resulting draft state, and full parameter documentation via the schema; no output schema exists so return values need not be explained. Slightly incomplete in that it doesn't say what happens if the recipe key is invalid or whether re-installation overwrites an existing draft.

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 every parameter is already documented (including cross-references like list_recipes and list_connected_apps). The description adds no parameter-level detail beyond what the schema provides, 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?

The description uses a specific verb ('installs') and resource ('recipe as a switched-off draft'), and clarifies the resulting state (inactive, awaiting owner review). It implicitly distinguishes the tool from create_automation_draft by scoping it to recipes, but never names the sibling explicitly.

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

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

The phrase 'for the owner to review' implies this is a staging/draft step rather than an activation, which gives some usage context. However, there is no explicit when-to-use guidance, no when-not conditions, and no named alternative (e.g., a publish or activate tool).

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 readOnlyHint annotation already tells the agent this is a safe read. The description adds useful context about returned content (actions and their action_config), but it does not mention pagination, auth, or return format; with annotations covering safety, that is a moderate gap.

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

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

Two sentences, front-loaded with the resource scope, followed by a compact integration instruction. 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?

The description covers resource scope, examples, and cross-tool integration for a zero-param read-only list tool. It does not describe the return shape or pagination, and with no output schema that leaves a small completeness 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?

There are zero input parameters, so there is no parameter meaning for the description to add. The schema is effectively complete, and the baseline for no params is 4.

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 the resource precisely: every action an automation can run, with examples and the action_config each needs. By naming list_connected_apps for triggers, it distinguishes its role from the sibling trigger-list 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?

It gives a concrete usage pattern: combine any trigger from list_connected_apps with any action. It does not specify exclusions or explicitly say to call it before create_automation_draft, so it is clear context but not full when/when-not 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, so the safety profile is covered. The description adds a genuine prerequisite the annotations do not carry — an Advance plan key — and notes that the id variant returns run stats, which is real behavioral context beyond structured 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 short sentences with no filler. The plan-key prerequisite is front-loaded, though placing the operational outcome ahead of the plan caveat would be marginally more agent-friendly.

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

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

For a one-parameter read tool with an output schema absent but a simple return shape, the definition covers prerequisites, both invocation modes, and the differing payload. Nothing an agent needs to call it 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 coverage is 100% and already documents the optional id. The description still adds meaning by tying the presence of id to a different response shape (single automation plus run stats), so it does more than restate 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?

States a specific verb and resource, and explicitly covers the two modes: listing all automations and fetching a single automation with run stats by id. It does not name or differentiate from sibling list_* tools, but the name plus description leaves no ambiguity about what is returned.

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 id clause implies when to use the single-fetch mode ('fetch one automation with its run stats by id'), which is useful conditional guidance. However, there is no mention of when not to use it or which sibling to prefer for other automation-related reads.

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, so the safety profile is covered. The description adds genuinely useful context beyond that: the tool fails without an Advance plan key. It says nothing about result size, pagination, or whether flows are filtered by workspace.

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

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

Two short sentences with no filler, and the plan requirement is stated up front so an agent can gate before calling. Minor deduction for leading with a prerequisite rather than the core 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 zero-parameter read tool this is close to adequate, but with no output schema the description should say what a "bot flow" entry contains or roughly how many come back. The Advance-plan prerequisite is the only non-obvious detail supplied.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no schema semantics left to compensate for. The description correctly implies no inputs are needed.

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 and resource ("List bot flows") and adds a scope qualifier ("available as automation actions"). That distinguishes it reasonably well from siblings like list_actions and list_automations, though it never explicitly states the contrast.

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

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

There is no guidance on when to call this versus list_actions or list_automations, and no exclusions or conditions beyond the plan prerequisite. The only usage signal is "Requires an Advance plan key," which is a gate rather than a when-to-use rule.

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, so the safety profile is covered. The description adds a genuine invocation precondition that annotations cannot express: an Advance plan key is required, which determines whether the call will succeed at all. It stops short of describing pagination, result limits, or ordering for the list mode.

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

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

Two short sentences with zero filler; the hard precondition is front-loaded and the dual-mode behavior follows immediately. Nothing is repeated from the annotations or schema.

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-optional-parameter read tool with no output schema, the definition covers the essentials: safety is annotated and the plan requirement is stated. However, it says nothing about the shape or volume of a campaign list (field set, pagination, ordering) or whether all campaigns or a workspace-scoped subset are returned, which leaves an agent guessing about result handling.

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 only parameter is documented as "Optional campaign id", so the baseline would be 3. The description earns above baseline by clarifying that the parameter switches the tool between two distinct modes (list all vs. fetch one), which the bare schema text does not make explicit.

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 campaigns") plus the alternate mode ("fetch one campaign by id"), which is more than the title alone conveys. It does not differentiate from the many sibling list_* tools (list_automations, list_templates, etc.), but "campaigns" is a distinct resource so an agent can still select 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 phrase "List campaigns, or fetch one campaign by id" implicitly tells the agent which mode corresponds to which parameter state, which is the main usage decision here. There is no explicit when-not guidance, no mention of how it relates to any sibling tool, and no note about what happens if the id does not exist.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation, and the description adds useful context beyond that: plan gating, intended sequencing before create_automation_draft, and the returned identifiers. It does not describe pagination or the full response shape, but it meaningfully supplements the annotation.

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 with the plan requirement, followed by the resource and sequencing guidance. Every clause adds useful information without 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 zero-parameter, read-only tool with no output schema, the description supplies the key operational context: plan requirement, what is returned at a high level, and when to call it. It could be slightly more explicit about the exact response shape, but it is adequate 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?

The tool has zero parameters, so there are no parameter semantics to explain. The baseline score for a zero-parameter tool is appropriate here.

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 identifies the resource: connected apps such as Shopify and WooCommerce, including their app_key and available event_key triggers. It does not explicitly start with a verb like 'List', but the tool name and content make the listing purpose clear and distinguish it from sibling create_automation_draft.

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 states a concrete prerequisite ('Requires an Advance plan key') and a sequencing rule ('call before create_automation_draft'). It does not name alternatives or exclusions, but the relevant usage context is clear.

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 readOnlyHint annotation already establishes that this is a safe read operation. The description adds a useful access constraint ('Requires an Advance plan key'), but it does not disclose pagination behavior, search semantics, or what the response contains.

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 two short sentences with no wasted words, and the access requirement is front-loaded. It is perhaps too terse for the available parameter surface, but structurally it is efficient.

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, three parameters with zero schema descriptions, and minimal annotations beyond readOnlyHint. The description does not fill those gaps, so an agent lacks enough context to call the tool precisely or understand the result 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 for the three undocumented parameters (page, limit, search). It references searching and listing only in passing and provides no meaning, format, or constraints for any parameter, leaving the schema's bare types to carry the 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 and resource: 'List and search inbox conversations.' It distinguishes the operation from the sibling get_conversation_messages reasonably well, though it does not explicitly name or contrast with that sibling.

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 when to use the tool (to list or search inbox conversations), but it does not state when to choose it over alternatives such as get_conversation_messages or list-related siblings. The 'Advance plan key' note is a prerequisite rather than usage guidance.

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

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

Annotations already declare readOnlyHint=true, and the description is consistent with that. It adds a genuinely useful prerequisite not present in structured data: an Advance plan key is required. It stops short of describing result volume, ordering, or pagination, so it isn't fully transparent.

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

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

Two short sentences with zero filler, and the hard prerequisite (plan key) is front-loaded before the functional statement. Every sentence 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?

For a zero-parameter read-only list tool with no output schema, the description covers the prerequisite and the nature of the results. A brief note that returned recipes carry identifiers usable with install_recipe_draft would close the last 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?

The tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly does not invent parameter discussion that would be irrelevant here.

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 ('proven ready-made automations') and clarifies the resource is installable as drafts, which distinguishes it from plain list_automations or list_templates. It never names a sibling explicitly, so the differentiation is inferential rather than explicit.

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 'can be installed as safe drafts' implies the downstream flow (browse recipes, then install_recipe_draft), giving an implicit usage context. There is no explicit 'use this when...' or exclusion against list_automations/list_templates, so the agent must infer selection.

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, so safety is covered. The description adds the plan-gating prerequisite, which is genuinely useful context, but says nothing about result shape, empty-state behavior, or whether the list is account-wide — modest added value beyond 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 short sentences with no filler. The plan prerequisite is front-loaded for easy scanning, though leading with the purpose statement before the access constraint would read slightly better.

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

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

For a zero-parameter, read-only listing tool with no output schema, the description covers purpose and access requirements. Only minor gaps remain, such as whether results are paginated or account-scoped.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly implies the call is unfiltered but doesn't need to say more.

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 ('tags'), scoped to tags exposed as automation actions. It is distinguishable from siblings like list_actions and list_automations, though the phrase 'available as automation actions' takes a moment to parse.

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 a real precondition — an Advance plan key is required — which helps an agent decide whether the call can succeed. However, it offers no guidance on when to prefer this over list_actions or other list_* siblings, leaving the selection implicit.

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, so the safety profile is covered. The description adds the plan-key requirement, which is genuine behavioral context an agent can act on, but says nothing about scope, pagination, or what happens on a non-Advance key beyond implying failure.

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

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

Two short sentences with no waste, and the blocking prerequisite is front-loaded ahead of the functional description. Every sentence 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?

For a zero-parameter read-only list tool with no output schema, the description covers the resource, its contents, and the access precondition. Only minor gaps remain, such as whether results are paginated or scoped to a workspace.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify; baseline 4 applies. The mention of "variables" correctly signals what the returned template objects contain, though no output schema exists to confirm 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?

States a specific verb (List) and resource (the client's approved WhatsApp templates plus their variables), which is clearly distinct from create_template and send_template. It doesn't explicitly name or exclude a sibling, so it falls just short of a 5.

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

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

"Requires an Advance plan key" is a useful prerequisite that tells the agent when this call will fail, but there is no guidance on when to prefer this over siblings like send_template or get_dashboard_stats. Usage context is implied by the verb rather than 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?

Annotations only say it isn't read-only and isn't destructive; the description adds genuinely useful context beyond that: a plan-tier authorization requirement and a hard limit on reversal (re-enabling is app-only, owner-only). It doesn't say what the call returns or whether in-flight executions are stopped, which keeps it 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?

Three short sentences with the access requirement front-loaded, then the action, then the safety constraint. Nothing is padded and no sentence repeats the name or schema.

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 mutation with sparse annotations and no output schema, the description covers the critical unknowns: authorization tier, what the call does, and the limits on undoing it. Only the result/confirmation behavior is left implicit, which is minor here.

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 `id` parameter is documented there as "Automation id." The description adds nothing about the identifier, but the schema already does the work, 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?

"Switches an automation OFF" states a specific verb and resource, and the explicit note that turning an automation back ON can only happen inside the app effectively distinguishes this tool from any hypothetical resume sibling. An agent knows exactly what this tool accomplishes 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?

It gives a clear prerequisite (Advance plan key) and an explicit when-not: don't try to re-enable an automation through the API, since the account owner must do that in the WALoops app. It stops short of naming alternatives or stating whether deactivation is immediate or reversible via other endpoints.

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

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

No annotations are provided, so the description carries the full behavioral burden. It mentions that a free OTP key sends from the WALoops WhatsApp number and that the channel may be whatsapp or sms, but it omits important side effects, delivery behavior, rate limits, permission requirements, and failure modes for an external send 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 two concise sentences with the core action front-loaded. There is no redundant or wasted text.

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

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

For a tool with four parameters, no annotations, and no output schema, the description is thin. It covers the basic action and channel behavior but omits the verification workflow, expected response behavior, and other operational details an agent would need to use it confidently.

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 75%, so most parameters are already documented. The description adds that the phone number should be international and clarifies channel values, but it does not add much beyond the schema, particularly for purpose or site_url.

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 and resource: sending an OTP to an international phone number. It clearly distinguishes this from the sibling verify_otp tool by focusing on sending rather than verifying.

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 this is the tool for initiating OTP delivery and notes channel options, but it gives no explicit when-to-use guidance, no mention of when not to use it, and no direct routing to verify_otp as the natural next step.

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 two real behavioral constraints – an Advance plan key is required and the template must already be approved. It says nothing about rate limits, whether the send is immediate or queued, what happens on unapproved templates, or what the response returns.

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

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

Two short sentences, front-loaded with the plan requirement and then the action plus the pre-step. Every clause carries information; 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?

For a 3-parameter send tool with no annotations and no output schema, the definition covers the essential prerequisite path but leaves gaps: no indication of what a successful send returns (message ID, status), delivery behavior, or failure modes for invalid numbers or unapproved templates.

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 'to', 'template', and 'variables' are already documented, and the baseline is 3. The description adds only a light hint that variables must match the template's expected values via the list_templates step; it does not explain the object-vs-array shape of 'variables' or the phone number format.

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 an approved WhatsApp template') with the key qualifier that only approved templates may be used. It names list_templates as the way to find template names, which distinguishes it from that sibling, though it does not contrast with create_template.

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 prerequisite workflow: 'call list_templates first to confirm the template name and variables.' It also states the plan requirement. It stops short of saying when not to use it (e.g., free-form/non-template messages), so no 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?

With no annotations, the description carries the entire behavioral burden. It does not disclose whether a successful verification consumes the code, whether failures are counted/rate-limited, or what a success/failure response looks like – all material for a security-sensitive verification action.

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 zero waste and the key scope term "previously sent" early. Efficient, though its terseness borders on under-specification for a tool with no 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?

For a simple 3-param OTP tool the purpose is clear and parameters are fully documented in the schema. However, with no annotations and no output schema, the description leaves return-value shape and error/consumption behavior entirely unexplained.

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 explains code, phone, and site_url in detail. The description adds no meaning beyond what the schema states, so 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 ("Verify") and resource ("OTP") with scope ("previously sent"), which cleanly distinguishes it from the sibling send_otp. It stops short of naming send_otp or get_otp_usage explicitly, so true sibling differentiation is only implied.

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?

"previously sent" implies a prior send_otp call is required, so the basic context is implied. But there is no guidance on when to use this versus get_otp_usage, nor on exclusions, prerequisites, or failure cases, leaving usage to inference.

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