morning_check

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

Annotations only declare readOnlyHint and openWorldHint, so the description adds genuine value: it discloses that the readiness figure is a model shaped like Garmin's and that Garmin's real Training Readiness is absent from the API, plus that 'today' is evaluated live and counts this morning's workouts. The main omission is cost/latency behavior for a tool that aggregates many metrics.

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?

The content enumeration is front-loaded and each item is informative for a composite tool, but the nested parentheticals (acute/chronic ratio, fitness/fatigue/form, the readiness component list) make it dense and slow to scan. The closing calibration sentence is valuable yet long-winded relative to the single instruction it carries.

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 output schema, the description carries the return-value burden and does so well by listing what comes back and flagging that the readiness score is an estimate rather than Garmin's. The remaining gap is date-parameter behavior, which matters because past days are clearly supported by the schema.

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 single `day` parameter has 0% schema description coverage and a bare default of 'today'; the description only obliquely implies date semantics via 'For today it is evaluated now'. It never states the accepted format for `day`, whether relative terms like 'yesterday' work, or how a past date changes the result (snapshot vs. live evaluation).

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 names a concrete resource — a composite recovery snapshot — and enumerates its contents (sleep, HRV, resting HR, Body Battery, recovery hours, training load, calories, stress, readiness), which is far more specific than a restatement of the name. It is distinguishable from siblings like readiness_history or training_load because it bundles them, though it never says explicitly 'use this instead of those'.

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?

Gives one explicit routing rule with a condition: when the user mentions their Garmin readiness score, call log_garmin_readiness so the estimate calibrates. That is real when-to-use-else guidance. However, there is no guidance on when to call morning_check versus readiness_history, daily, or training_load, so the agent must infer the boundary.

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