get_quotation_win_rate

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

With no annotations, the description carries the burden of explaining the operation. It discloses the key behavioral output: conversion rate, average deal value, open/won/cancelled counts, and a by-customer breakdown. The verb 'Shows' implies a read-only analytical report, which is a sufficient behavioral cue for this type of tool. It does not detail edge cases or data freshness, but the core behavior is 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 sentences with no waste. The first sentence is front-loaded with the tool's core purpose and output details; the second provides a practical use case. Every clause adds useful 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?

For a two-parameter read-only report with no output schema, the description enumerates the returned metrics and explains why it would be used. It lacks explicit statement of read-only safety and does not mention how the date range interacts with the grouping, but these are minor given the 100% schema coverage and simple parameter object.

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

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

Schema description coverage is 100%, with both toDate and fromDate clearly documented including defaults. The description does not add any parameter nuance beyond the schema, so the baseline score of 3 is appropriate because the schema carries the semantic 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 names a specific resource (sales quotations) and a specific analytical verb (Shows win-rate/conversion analysis), then enumerates the exact metrics returned. This clearly differentiates it from broader siblings like get_sales_analysis or get_open_quotations.

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

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

It gives an implied use case ('sales pipeline and forecast accuracy assessment') but does not state when to prefer this over alternative sales-analysis siblings, nor when not to use it. No exclusions or alternative tool names are provided.

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