Retrieve recent sleep records sorted by wake time, with an optional day window defaulting to 14 days, to review session durations and daily sleep totals.
最近的睡眠记录（需要 app 3.8+），按醒来时间倒序，默认 14 天窗口。
minutes 是单次时长；day 是这条被归到的日历日（醒来的那天），今天的总量看 today_minutes。
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses a client version prerequisite ('需要 app 3.8+'), the sort order (descending by wake time), the default window (14 days), and the meaning of returned fields (minutes = per-session duration, day = attributed calendar day, today_minutes = today's aggregate). Gaps remain around pagination/limits and how records are truncated at the window boundary.
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 blocks: the scoping facts first (recency, version requirement, ordering, default window), then field semantics. Every sentence carries information, though the parenthetical version note is slightly interrupting and the field glossary could be tighter.
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?
There is no output schema, no annotations, and 0% parameter documentation, so the description is the only source of truth. It covers output field meaning and default behavior, but omits read-only framing, result limits, and explicit parameter semantics for 'days' — leaving real gaps for an agent deciding how many days to request.
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% and the single 'days' parameter is undocumented in the schema, so the description must compensate. It does partially by stating a default 14-day window, which implicitly defines what the parameter controls, but it never names the parameter, its units, its maximum, or what happens at boundary values.
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 specific resource and verb equivalent ('最近的睡眠记录' / recent sleep records) and adds ordering ('按醒来时间倒序') plus a default window ('默认 14 天窗口'), so an agent can distinguish it from the write-side sibling log_sleep without opening the schema. It stops short of explicitly naming siblings or stating what it is not (e.g. vs today_summary), which keeps it off a 5.
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?
Usage is implied rather than stated: 'recent records' with a 14-day default signals when the tool is appropriate, and '今天的总量看 today_minutes' redirects for today's total. However there is no explicit when-to-use / when-not-to-use framing and no pointer to a named alternative tool such as log_sleep or today_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.