list_durability_runs

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds genuinely new behavioral context ('No GPS is returned') that prevents an agent from expecting coordinate data, plus a date format note. It still says nothing about pagination behavior, result ordering, or the missing/null-date case, so it adds some value rather than rich context.

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 compact sentences with no filler, and the core scope statement comes first. The comma-separated status list ('status signal, no_signal or not_evaluable') is slightly awkward and its relationship to the arguments is ambiguous, but nothing is wasted.

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?

Annotations and an output schema carry much of the burden, so the description needn't explain return values. For a paginated list tool, however, key facts are missing: whether results are ordered, how limit/offset interact, whether the status filter is fixed or selectable, and what the tool does when no dates are supplied.

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 0% for four parameters, so the description must compensate. 'Dates are YYYY-MM-DD' usefully pins the format for start_date and end_date, but limit and offset are left entirely unexplained beyond their defaults. Worse, the description foregrounds a status filter ('status signal, no_signal or not_evaluable') that has no corresponding parameter, which can send an agent hunting for a non-existent argument.

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 ('List outdoor runs') plus the status scope ('status signal, no_signal or not_evaluable'), so the agent knows the operation and its filter. It does not differentiate from the siblings get_durability_indices and get_durability_trend, leaving the choice between 'list runs' and 'get indices/trend' to inference.

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?

There is no explicit when-to-use guidance and no alternative named. The status clause hints at scope, but an agent is never told when to pick this list endpoint over get_durability_indices or get_durability_trend, nor when a date range is required versus optional.

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