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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safe-read profile is covered. The description adds useful context about free preview versus Pro Council Grade, the upgrade path via Anansi Haven Room / $ANANSI, and an informational-only disclaimer, but it does not discuss rate limits, output format, or validation 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?

The description is a single dense sentence but front-loads the core purpose and then layers on access tier and disclaimer. It is appropriately sized for a complex 16-parameter grading tool, though the marketing and upgrade-path clauses are somewhat packed into the same sentence as the functional description.

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?

Given the tool's complexity, lack of output schema, and 16-parameter input schema, the description provides a solid overview of what is scored and what access tiers exist. It does not fully specify return format or explicit alternatives, but the scoring components and disclaimer make it sufficiently complete for an agent to understand the tool's role.

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%, so the baseline is 3. The description adds meaning beyond the schema by explaining how inputs feed the analysis: MFE/MAE excursion expectancy, stop-loss placement against empirical symbol ATR/MFE/MAE benchmarks, R-multiple capture, and rule compliance involving rollover window, stop floor, and time-stop.

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 and set of operations: trade postmortem, MFE/MAE excursion expectancy analysis, entry/exit efficiency scoring, stop-loss benchmark comparison, R-multiple capture, and rule compliance. It is clear what the tool does, but it does not explicitly distinguish itself from the sibling trade_postmortem tool, leaving some ambiguity about which postmortem tool to choose.

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 'Trade postmortem & MFE/MAE excursion expectancy analyzer' implies the tool is used to review completed trades, and the free/pro split suggests tiered access. However, there is no explicit 'use this when' guidance, no when-not-to-use conditions, and no named alternative such as trade_postmortem or position_size for comparison.

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