Retrieve nightly sleep summaries for each day in an inclusive date range to analyze rest patterns from Garmin data.
多日睡眠汇总。与官方客户端 get_daily_sleep_summaries 一一对应。参数和日期限制沿用官方接口。Return daily sleep summaries for an inclusive calendar date range.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | ||
| start_date | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description only says date limits 'follow the official interface' without stating what those limits are, so the one behavioral constraint it gestures at is unactionable. No pagination, result-size, or permission context is provided.
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?
Short overall, but split across Chinese and English with duplicated content and a self-referential sentence about matching the official client that earns no place. The actual behavioral content is only the final English sentence.
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?
No output schema and no parameter descriptions anywhere, so the description must carry the load — yet it omits the date format, the maximum range implied by 'date limits', and what a summary record contains. For a data-retrieval tool with required date bounds, these are material gaps.
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%, and the description supplies only that the range is an 'inclusive calendar date range' — useful (endpoints inclusive) but silent on the date string format, timezone basis, and any max span. It partially compensates for the empty schema but leaves an agent guessing at formats.
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 ('Return daily sleep summaries') plus the 'multi-day' scope, which implicitly separates it from the single-day sibling get_daily_sleep. The bilingual restatement and the meta-note about matching the official client add no distinguishing information but don't obscure the purpose.
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 'multi-day' / 'date range' framing hints that this tool is for spans rather than a single night, implying get_daily_sleep is the alternative, but no sibling is named and no when-not-to-use condition is given. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.