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). The description adds genuine behavior beyond that: results are computed with the same function as a named public calculator rather than estimated, and the response includes inputs, unit-labeled results, the formula, and a page link. It also discloses the 'educational, not investment advice' disclaimer that the annotations do not convey.

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 sentences, front-loaded with the computed outputs so an agent immediately knows what it gets. The calculator-provenance and disclaimer sentences earn their place given the absence of an output schema, though the two provenance clauses could be tightened into one.

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 carries the return-value burden and does so adequately: inputs echoed, results with units, the formula, and a page link. Combined with 100% schema coverage and rich annotations, an agent has enough to call and interpret it, though the absence of any usage routing keeps it short of 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 description coverage is 100%, so the schema already documents winRate as percent, avgWin/avgLoss as positive same-unit amounts, and lang as en/zh. The description only restates the inputs ('from a win rate and average win and loss') and adds no constraint or unit detail beyond the schema — 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?

Names the exact metrics produced (expectancy per trade, per 100 trades, payoff ratio, break-even win rate, profit factor) and the exact inputs (win rate, average win/loss). This clearly differentiates it from siblings like calculate_kelly_criterion or calculate_risk_reward, which take different inputs and yield different outputs.

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 input/output framing — an agent can infer this is the tool for expectancy math, but the description never states when to prefer it over siblings (e.g. kelly criterion, risk-reward) or any exclusions. No explicit routing guidance is present.

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