get_coaching_context

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

No annotations are provided, so the description carries the full burden; it implies a read-only aggregate via 'Everything needed...' but never states it explicitly, nor does it mention cost/size of a fan-out call or whether anything is persisted. The period-ignored-over-date-range rule and broker-suffix normalization exist only in the schema, not the prose.

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?

One sentence, front-loaded with the value proposition before the content list. The itemized enumeration is dense but each element conveys distinct return content rather than filler; there is mild redundancy with the output 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?

An output schema exists, so return values need not be explained, yet the enumeration usefully signals breadth for selection purposes. With four optional params fully documented and no side effects implied, the main omission is any statement of read-only behavior or call weight, which matters for an aggregate fan-out tool.

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 all four optional params documented (defaults, date format, suffix handling), so the schema does the work. The description adds no param-level meaning beyond hinting that a comparison period is involved. 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?

The description states a concrete composite deliverable ('everything needed for a coaching review in one call') and then enumerates the payload: stats vs previous period, per-instrument verdicts, breakdowns, behaviour flags, best/worst trades, notes, rules and prior action plan. That enumeration is what separates it from sibling aggregation tools like get_performance, get_instrument_breakdown and get_behavior_report. The verb is only implicit via the name, which keeps it out of the top band.

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?

'In one call' hints that this is the batch alternative to calling the individual breakdown/report tools, but the description never names those siblings or states when to prefer them. There are no exclusions, prerequisites, or guidance on period vs. explicit date ranges (which would matter since period is ignored when dates are supplied).

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