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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the bar is lower. The description still adds genuinely non-obvious behavior: numbers are frozen as of created_at, captainDecisionPoints mirrors the app's armband score per projectionNotes, and cross-account ids return not found rather than an auth error.

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 short sentences, front-loaded with the core action before the snapshot caveat and the not-found rule. The 'armband score' phrasing is domain jargon, but it is immediately anchored to projectionNotes so it stays parseable.

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?

A one-parameter read with no output schema needs the description to carry return-shape context, and it does point at created_at snapshot semantics and specific fields (captainDecisionPoints, projectionNotes). It stops short of describing the overall response structure, which is acceptable for a simple getter.

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 schema documents the single suggestionId at 100% coverage including pattern and length bounds. The description only re-states 'by its id' and adds the ownership rule that a foreign id yields not found, which is useful but marginal beyond the schema.

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?

States a specific verb and resource: 'Read one saved analysis by its id for the authenticated account.' The 'by its id' framing separates it from the sibling get_latest_fplai_analysis, though it never names that sibling explicitly, so an agent must infer the contrast.

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: this is the id-addressed retrieval path, and a foreign or unknown id returns not found. There is no explicit statement of when to prefer it over get_latest_fplai_analysis or run_fplai_analysis, leaving the routing decision to inference.

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