Calculate average steps for each hour of the day by period to show when you are active and identify movement patterns.
Average steps for each hour of the day (0-23), per period. Shows when you move.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | ||
| home_only | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden and mostly does not carry it. It never confirms this is a read-only aggregation, never says what happens when period is omitted (null default), and never mentions that the default home_only=true silently filters the data — a behaviorally material default.
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?
Two short sentences with no filler, and the metric plus grouping are front-loaded. It is arguably trimmed below usefulness, but there is no wasted phrasing to cut.
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 tool with zero schema description coverage, no annotations, and no output schema, the description leaves critical gaps: the meaning of home_only, the accepted period format, and the granularity of the result (per-period hourly buckets). An agent could call it, but not confidently predict the output.
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 0%, so the description must compensate and only partly does: "per period" implies period defines the aggregation window but gives no format or accepted values (including what null means). The home_only parameter — the one that most changes results — is not referenced at all.
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 metric (average steps), a specific grouping (hour of day, 0-23), and a scoping qualifier (per period). The tabular shape is clear enough to distinguish it from weekday_profile or monthly_trends without further inspection, though no sibling is named explicitly.
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?
"Shows when you move" is a hint at the use case but not a directive: there is no statement of when to pick this over weekday_profile, overview, or compare_periods, and no prerequisites or exclusions. The agent must infer the choice from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.