Waply for Kommo

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavioral context: incoming calls are free, the rate is an unverified heuristic rather than an official Meta tariff, the result must be presented as a reference estimate needing rate-card confirmation, and Waply plans, AI/provider fees and taxes are excluded. This is exactly the kind of caveat an agent cannot get from 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?

Purpose is front-loaded in the first clause, and each following sentence carries non-redundant information (free incoming, heuristic caveat, exclusions). No filler or restatement of the tool name.

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

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

With no output schema, the description still implies the returned value is a total estimate and flags the required disclaimer, plus lists what is out of scope. A minor gap remains around the shape/currency of the returned estimate, but for a 3-parameter read-only calculator this is close to sufficient.

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

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

Schema coverage is 67% with both market and outgoingMinutes documented in-schema (locale is an obvious enum). The description nonetheless reinforces parameter meaning by framing minutes as outgoing-only monthly minutes and by tying market pricing to a reference rate, though it adds little about the locale enum that the schema does not already convey.

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 ('Estimate WhatsApp outgoing call costs from monthly minutes') and clarifies scope by stating 'Incoming calls are free', which naturally separates it from calculate_message_cost. It never names a sibling tool explicitly, so differentiation rests on the resource noun rather than direct routing language.

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: estimate call costs from a monthly minute figure, tied to the same reference rate as Waply's web calculator. There is no 'use this instead of X' routing and no stated precondition beyond the inputs, so an agent must infer when this beats calculate_message_cost or compare_message_costs.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description adds genuinely useful context beyond them: the exclusion of Waply plans/taxes/international authentication, and the caution that this is a snapshot-based estimate rather than a live rate lookup. The only missing behavioral detail is pagination/rounding, which is minor here.

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?

Five tight sentences, front-loaded with purpose, then rate-card choice, then return shape, then scope limits, then the response-formatting instruction. Every sentence carries distinct information and 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?

With no output schema, the description usefully enumerates the return shape ('total, category breakdown and free service allowance') and points at the rate-card date, which the formatting instruction reinforces. Given 8 parameters at 88% schema coverage, the only gaps are edge-case behavior (all-zero inputs, rounding) that an agent can safely omit.

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 88%, so the schema already carries nearly all parameter meaning, including the mode enum and the market/allowance rules. The description adds only the 'current or October 2026 rates' framing for mode, which the schema already states more precisely. Baseline 3 is appropriate when the schema does the heavy lifting.

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 specific verb+resource: 'Estimate monthly WhatsApp message costs in USD', with the mechanism named ('same rate snapshot and calculation as Waply's web calculator'). It distinguishes itself from most siblings (list_meta_pricing_markets, get_plan_details) but never explicitly contrasts with calculate_call_cost or the very similar compare_message_costs, which an agent must infer from the singular 'Choose current or October 2026 rates'.

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?

Scope exclusions are stated ('Meta costs only; excludes Waply plans, taxes and international authentication'), which tells the agent when this tool is not the right answer. However, no alternative is ever named — not compare_message_costs for multi-card comparison, nor calculate_call_cost for the call-side estimate — so routing 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 declare readOnly, idempotent, non-destructive and closed-world. The description adds genuinely useful behavioral context beyond that: free-window traffic distribution is not inferred, and Waply plans and taxes are excluded, which sets expectations about what the result does and does not cover.

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 that carry the comparison scope, return shape, and exclusions with minimal waste. Nothing redundant, though the middle sentence about free-window inference is slightly dense for its information value.

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

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

For a 7-parameter, no-output-schema tool, the description covers what comes back (totals, breakdowns, difference) and the key modeling caveats and exclusions. Only the relationship to the sibling calculation tool is left implicit, which is a minor gap.

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

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

Schema description coverage is 86%, so the schema already documents most parameters in detail (service, utility, marketing, phoneCount, authentication, market). The description adds little per-parameter meaning, only the general notion of sharing the same volume across both cards, which is the baseline 3 case.

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: compare monthly message volumes across the current and October 2026 Meta rate cards, and names the returned artifacts (both USD totals, breakdowns, October-minus-current difference). This distinguishes it cleanly from the sibling calculate_message_cost, which produces a single cost rather than a two-card comparison.

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?

Frames the scenario (comparing the same volumes under two rate cards) and states it matches the web calculator, plus scoping exclusions (Waply plans, taxes). It does not explicitly name the alternative tool or state when not to use this in favor of calculate_message_cost, so it stops short of clear routing guidance.

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

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, and the description usefully adds a negative capability statement ('does not install Waply or modify Kommo') that prevents a plausible misread of the tool name. It also discloses that the response includes a localized suggested message, which is not derivable from the schema.

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 primary action, then the routing rule, then the boundary disclaimer. 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?

For a simple, annotated, single-parameter read tool with no output schema, the description covers what is returned, when to use it, and what it does not do. It stops short of explaining the guideUrl field's origin or fallback behavior when locale coverage is limited.

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

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

Schema coverage is 0%, so the description carries the burden, and it only indirectly implies what 'locale' does via the phrase 'localized suggested response'. The enum values (en/es/pt/id/tr) are self-explanatory language codes, so the gap is modest but real.

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 ('Get the direct Waply installation link for Kommo') and even characterizes the return payload (link plus a short localized suggested response). It does not explicitly differentiate itself from the nearby 'list_guides' or 'search_documentation' siblings, which keeps it 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?

Gives an explicit trigger ('For installation requests'), an ordering instruction ('lead with this clickable link'), and a conditional escape hatch ('offer guideUrl only if the user asks for instructions or requirements'). This is exactly the when-to-use guidance an agent needs.

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, non-destructive, idempotent, and a closed world, so the safety profile is largely covered. The description reinforces this by stating it does not start a trial or purchase, which adds business-level clarification about the absence of commitment. However, it says nothing about what 'terms' the response includes, the public/non-authenticated nature, or the return behavior.

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

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

Two short sentences, with the resource and the negative scope front-loaded and zero filler. Nothing is repeated and nothing is wasted.

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

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

For a three-parameter lookup with no output schema and strong annotations, it covers the core 'what' but leaves real gaps: it doesn't specify which fields 'terms' returns, whether pricing varies by locale beyond language, or that all three parameters are mandatory. An agent could call it but might have to retry after seeing the result format.

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 should explain the three required parameters, and it explains none of them. It never says that 'locale' controls the language of the returned terms, that 'period' selects billing cadence, or what distinguishes the four plan tiers; the enum values are self-describing, but they carry only part of that 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?

It states a specific verb ('Read') and a specific resource ('public Waply plan prices and terms'), which is enough to distinguish this from the calculation-oriented siblings. But it doesn't explicitly name any sibling (e.g., calculate_call_cost, list_meta_pricing_markets) that could otherwise seem related, so differentiation is implicit.

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

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

The description gives one useful exclusion: it doesn't start a trial or purchase, so an agent won't mistake this for the subscription step. But it never says when to use this tool vs. the monthly-cost calculcators or pricing-market tools, so the agent has to infer the boundary.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so "Read-only" is largely redundant with structured data. The description does add useful behavioral context by disclosing the per-locale granularity of results, but omits pagination, result-size limits, and ordering for a potentially multi-locale list.

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

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

Two tight sentences: resource and returned fields first, then the optional-parameter rule. No filler, nothing wasted.

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

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

With no output schema, the description helpfully names the returned fields, so an agent knows the response shape. The only gap is list behavior at scale (pagination/ordering), which matters when locale is omitted and all locales are returned.

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 carry the locale parameter's meaning — and it does, explaining that omitting locale returns every published locale. It does not restate the enum values, but the schema already enumerates them, making that unnecessary.

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 Waply public guides") and enumerates the fields returned (title, description, last update, URL), which goes beyond a bare restatement. It distinguishes itself implicitly from siblings like get_installation_guide and search_documentation, though it never names an alternative 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?

"Omit locale to get every published locale" is a genuine usage rule for optionality. However, there is no guidance on when to prefer this over search_documentation or get_installation_guide, so routing among siblings 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 cover readOnly, idempotent, non-destructive, and closed-world behavior, so the bar is lower. The description still adds useful context by declaring 'Public information only' (no auth/private data involved) and disclosing that results carry localized labels and exact IDs.

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, front-loaded sentences with no filler; the primary action leads and the workflow hint follows. The closing 'Public information only' clause is slightly tacked-on but still carries information.

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

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

With no output schema, the description partially fills the gap by naming what comes back (localized labels and exact IDs). The locale parameter's effect on results remains unexplained, and no pagination or result-size behavior is mentioned, so it is not fully complete.

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

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

Schema coverage is 50%: 'query' is documented in the schema, but 'locale' has only an enum with no explanation. The description gestures at localization and country/regional-group search, which partially compensates, but never explains that 'locale' controls the language of the returned labels.

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 destination markets supported by the WhatsApp cost calculator) and even describes the payload content (localized labels and exact IDs). It distinguishes itself from the calculate_* siblings only implicitly via 'before calculating', without naming them, so it falls 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?

Gives clear context: use this to search a country or regional group before performing a calculation. This establishes the tool's place in the workflow, but it names no alternative tools and gives no explicit when-not condition (e.g., when to skip this and go straight to calculate_message_cost).

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 annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so 'never changes an account' largely repeats structured data. The one genuinely new behavioral fact is the result cap ('at most five guides'), which is disclosed nowhere else — a useful but singular addition.

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 front-loaded sentences with no filler; the purpose is stated first and the constraint second. The 'never changes an account' clause is slightly redundant against the annotations, costing it a perfect score.

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 two-parameter read tool with no output schema, the description covers the essentials and adds the result cap. It remains incomplete on parameter semantics and on how search differs from the sibling guide-listing tools.

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

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

Schema description coverage is 0% and both parameters are required, so the description carries the full burden — yet it says nothing about the 'query' string semantics or the 'locale' enum values (en/es/pt/id/tr). The enum is machine-readable but the intent of choosing a locale is left unexplained.

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 ('Search Waply public documentation') with a scoping qualifier ('public'), which is clearer than a bare name restatement. It is distinguishable from siblings like list_guides or get_installation_guide, though it never names them, so the differentiation is only implied 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 description gives no when-to-use or when-not-to-use guidance, nor does it mention the obvious alternative (list_guides) for browsing rather than searching. An agent must infer the search-vs-list distinction entirely on its own.

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