Winback: pay-on-success win-back

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

Annotations only declare readOnlyHint and closed-world, so the description carries the rest of the burden and does so richly: it discloses the fee (15%), the 6-month cap, default rates, the provenance of each rate (RevenueCat SOSA 2026 vs. explicit assumptions), and warns the cancellation rate is a reference, not a forecast. That is exactly the kind of context annotations cannot supply.

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?

It is a single dense sentence that front-loads the formula and then the defaults, with no filler. The stacked-clause structure is slightly run-on, but every clause (fee, cap, provenance, caveats) 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?

With no output schema, the description should ideally say what comes back (a per-segment estimate, a total, net-of-fee), which it only implies via the formula and fee mention. Otherwise it is complete: inputs, defaults, ranges, cap, and caveats are all covered for this read-only estimator.

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 already 100%, so 3 is the floor, but the description goes further by explaining how the parameters combine (segment loss × return rate × price, capped at 6 months, minus the 15% fee) and by labeling months_paid as an upper bound and each return rate as default/assumption. This gives the agent meaning beyond the per-field strings.

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+resource (estimate win-back revenue) and even pins the exact formula and source calculator, so an agent knows precisely what computation runs. It does not explicitly differentiate itself from siblings like get_winback_pricing, but the purpose is unambiguous 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?

There is no explicit when-to-use or when-not-to-use guidance, and no mention of the sibling tools. The clause 'a reference not a forecast' hints at how to interpret the output but never states the conditions under which this tool should be selected over get_apple_retention_facts or get_winback_overview.

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 openWorldHint=false, so the agent knows this is a safe, closed-domain read. The description adds useful framing with "Sourced facts," implying curated/authoritative content, but says nothing about volume, freshness, or how the facts are returned.

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 sentence that front-loads the resource domain and ends with the audience cue. No filler, no repetition of the title or 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 zero-param read tool the description is serviceable, but with no output schema it never indicates the form or scope of the returned facts (a list? prose? per-topic sections?), leaving the agent to guess at the response shape.

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

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

The tool takes zero parameters, so there is no parameter semantics for the description to compensate for. The baseline for a parameterless tool is a 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 names a specific resource domain (App Store billing retry, grace periods, win-back offers, Retention Messaging) with a stated audience, so an agent knows exactly what content this tool surfaces. It does not, however, differentiate itself from siblings like get_winback_overview or get_winback_pricing, which sit in the same topical neighborhood.

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?

"For founders planning a win-back" implies a usage context but stops short of stating when to call this versus get_winback_overview or get_winback_pricing, and offers no exclusions. Usage must be inferred from the topic overlap with 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 establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the tool surfaces limitations ('what it does not do') and prerequisites ('what it needs'), which signals this is a static knowledge response rather than an action, but it says nothing about response format or scope boundaries.

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, no waste, with the content summary and the usage trigger both front-loaded. The opening list mildly restates the title ('What Winback does') but the enumeration of audience, requirements, and limits 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 informational tool, the description is sufficient to route the agent correctly: it says what the tool covers and when to invoke it. Since there is no output schema, a brief note on the kind of content returned would have added value, but nothing essential is missing.

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

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

The tool takes zero parameters, so there is no parameter semantics to document; the baseline for a 0-param tool is 4. Nothing in the description misleads about inputs.

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 resource (Winback) and specifies the content it delivers: purpose, target audience, prerequisites, and explicit limitations. This distinguishes it as the orientation/overview entry point among the siblings (pricing, revenue estimate, retention facts), though it never explicitly contrasts itself with them.

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 trigger: 'Use this when someone asks how to win back churned subscribers of an iOS, Android or Stripe subscription app.' That is a clear when-to-use condition, but no when-not-to-use guidance or named alternatives (e.g., for pricing questions use get_winback_pricing) are provided.

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 openWorldHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that - no indication of what the terms contain, freshness, or 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?

The single fragment is short but fails to earn its place - it is under-specification rather than conciseness, conveying no more information than the tool name already does.

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 zero-parameter read with no output schema, the description still fails to say what 'terms' are returned or how they differ from the sibling winback tools, leaving the agent unable to judge relevance.

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 schema-based baseline of 4 applies; there is nothing for the description to clarify or compensate for.

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 'Winback pricing terms' restates the tool title ('Winback pricing') almost verbatim and contains no verb describing an action. It does not distinguish this tool from its siblings such as get_winback_overview or estimate_win_back_revenue, so an agent cannot tell what is actually being fetched.

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 statement of when to use this tool, when not to, or how it relates to the three sibling tools in the winback family. The agent receives no routing guidance at all.

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