oura_baseline_drift

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

No annotations are provided, so the description carries the full burden. It discloses the output includes deltas, z-scores, and flags, and states interpretation is left to the caller, indicating it returns raw metrics without analysis. It does not explicitly state whether the operation is read-only or if any side effects exist, though as an analysis tool it is likely safe. Given missing annotations, more explicit behavioral disclosure would be expected.

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 a single, well-structured sentence that front-loads the core computation, lists the metrics, and closes with an interpretation caveat. It contains no filler or redundant phrases, making it highly efficient.

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 and no annotations, the description should detail return format and parameter semantics. It mentions the metrics and flags but not the exact structure of the response. The 'days' parameter remains unexplained, leaving a gap in parameter understanding. For a two-parameter tool, this is a notable incompleteness.

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 has 0% description coverage, so the description must compensate. It explains 'window' as the period over which drift is measured, but does not define 'days', which likely represents the baseline period. The agent is left to guess the meaning and relationship of 'days' to the window, creating ambiguity for parameter usage.

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?

Description clearly states the tool computes baseline drift metrics (nightly lowest HR, average HR, HRV, respiratory rate, temperature deviation) over a window vs preceding baseline, with deltas, z-scores, and flags. It distinguishes itself from siblings like oura_sleep_periods (raw data) or oura_temperature_shifts (temperature-specific) by specifying a multi-metric drift analysis. The resource and computation are unambiguous.

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 implies use for analyzing baseline drift but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives or criteria for selecting this tool over siblings. An agent must infer its purpose from context, which is possible but not explicitly supported.

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