wearable_summary

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

Annotations already declare readOnlyHint and openWorldHint. The description adds meaningful behavioral context beyond that: data is opt-in, sourced from the user's own instance, and returned only as aggregates rather than raw records. This clarifies privacy and scope expectations without contradicting the annotations.

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 description is compact with data types front-loaded, and the second sentence adds a clarifying constraint. There is minor redundancy between 'Aggregated' and 'returns aggregates only', but overall every sentence earns its place and the tool is easy to scan.

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 simple read-only tool with an output schema, the description covers the source, privacy condition, and aggregate nature of the data well. The main gap is the undocumented 'days' parameter, which leaves the caller without full information about how the aggregation window is controlled. It remains callable with defaults, so this is a moderate rather than fatal omission.

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?

There is one parameter, 'days', and schema description coverage is 0%. The description does not mention or explain this parameter at all. The title 'Days' plus default/min/max give some hint that it controls the aggregation window, but the description was expected to compensate for low schema coverage and does not clarify whether it is a rolling window, calendar days, or something else.

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 identifies a specific resource ('the user's own Open Wearables instance') and enumerates the exact data domains covered: sleep, resting heart rate, steps, and workouts. 'Returns aggregates only' supplies the action and distinguishes it from sibling tools that handle profiles, plans, and adherence. It could be slightly more explicit about being a summary/retrieval operation, but the intent is clear.

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?

The description gives clear context: this is appropriate when the agent needs aggregate wearable metrics from the user's own opted-in Open Wearables data. It also implies a limitation (only aggregates, no raw records) and a prerequisite (opt-in). It does not name alternatives or explicitly say when not to use it, but the context is sufficiently concrete.

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