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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's added value is the scrum-only precondition and the possibility of a not_implemented result while the daily snapshot is being built. That is a genuinely useful failure-mode disclosure an agent could not infer from the schema. Return payload shape is not described, but no output schema exists to offset it.

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 purpose before the constraints. No filler; the only mild redundancy is restating 'scrum only' twice (title and body).

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?

For a two-parameter read with full schema coverage and no output schema, the description covers scope, iteration pattern, and the not_implemented case. What the returned series actually contains (dates, points units, date range) is left implicit, which is the remaining gap.

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% and both parameters carry patterns and examples, so the description's only addition is the 'one sprint per call' constraint on sprint_id. That is a marginal semantic gain over structured fields, making the baseline 3 correct.

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 first sentence names the specific resource and metric (daily remaining points) and constrains it to a sprint, in scrum mode only. That separates it from siblings like get_summary, get_project_insights, or list_sprints, though it does not explicitly name those alternatives.

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?

It gives a clear calling pattern: one sprint per call, repeat per active sprint when several exist. It also sets expectations for the not_implemented response and instructs the agent to surface that to the user. It stops short of pointing to list_sprints for discovering sprint ids, which would complete the routing story.

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