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

The description restates all four annotation values verbatim, which adds no information beyond the structured fields, though it does gloss readOnlyHint with 'reads a published scorecard, mutates nothing' and adds the useful scope caveat 'Not user P&L'. It discloses nothing about what the scorecard actually returns, whether results are time-stamped or cached, or what 'prospective' implies — with annotations present the bar is lower, but this earns only a middling score.

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?

Extremely short and front-loaded, with the most useful scoping fact ('Not user P&L') appearing early. It is telegraphic sentence fragments rather than structured prose, and the verbatim annotation enumeration is low-value padding, but there is no rambling to cut.

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 parameters and no output schema, the description carries the burden of explaining what a caller gets back — and it never says. 'Scorecard', 'methodology' and 'prospective signal observations' are left undefined, so an agent knows the tool is a free read-only public lookup but not what it would actually receive or how to use the result alongside mnemos_arb_scan or mnemos_bars.

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 and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-level meaning is missing.

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 indicates the tool surfaces a published scorecard containing public methodology and 'prospective signal observations', which is more informative than the bare name. But it never uses an explicit verb ('returns', 'retrieves') and never distinguishes this from siblings like mnemos_decisions or mnemos_status, so an agent must guess where this fits in the toolset.

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 only routing-style guidance is the negative 'Not user P&L', which rules out one misuse but says nothing about when to prefer this over mnemos_astra_scorecard's siblings. No prerequisites, no trigger conditions, no named alternative.

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