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 safety profile is fully covered by structured data and the description is not required to carry it. The description adds only the filtering behavior and the accepted date format, and says nothing about ordering, result limits, or what happens when both a date range and a timeframe are supplied.

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?

A single front-loaded sentence that states the resource, the two scoping modes, and a concrete example with no filler. Slightly more could be earned by folding the sibling guidance into that same compact line rather than leaving it out entirely.

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?

This is a simple, zero-required-parameter read tool with a small schema and no output schema, so the definition is nearly complete for the complexity involved. The residual gap is the unaddressed interaction between timeframe and startDate/endDate, plus no hint about default behavior when no parameters are passed.

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 67% and the schema's own descriptions are terse ('YYYY-MM-DD', a two-value enum), so the description's worked example (startDate 2026-11-01, endDate 2026-11-30) does add real value about pairing and format. It still does not explain the relationship between the timeframe enum and the date parameters — whether they are mutually exclusive or which wins — which is the main ambiguity an agent would face.

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 gives a specific verb and resource ('List goals') plus the two supported filtering modes (date range or timeframe), so the agent knows exactly what the tool returns and how it can be scoped. It falls short of a 5 because it never distinguishes itself from the closely related siblings get_todays_goals, get_week_goals, and get_goals_for_task.

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 implied by the date-range framing and the concrete example, which tells an agent this is the tool for arbitrary windows. However, no alternative is named, so an agent looking for today's or this week's goals has no signal telling it to prefer get_todays_goals or get_week_goals over this tool, and there are no stated exclusions or prerequisites.

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