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

With no annotations, the description carries the full burden and only partially meets it. It usefully discloses the date format (ISO) and sort order (newest first), but says nothing about authorization, rate limits, how 'limit' interacts with the date range, or what an empty date_from/date_to means.

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 terse fragments, front-loaded with the returned metric set and followed by the format/ordering note. No filler, no restatement of the tool name.

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?

An output schema exists, so return values need not be explained. But with zero annotation coverage, zero schema description coverage, and no sibling differentiation, an agent still lacks enough to decide between this and the granular sleep/heart-rate tools or to reason about the default empty date bounds.

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%, so the description must compensate for all three parameters. It only clarifies date format and ordering, which partially covers date_from/date_to, and leaves 'limit' (default 30) and the empty-string date defaults entirely unexplained, including whether no limit is applied or capped.

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 (daily metrics) and enumerates the exact fields returned (recovery, RHR, sleep, strain, TRIMP, CTL/ATL/TSB, SpO2, steps), which is far more specific than the bare name. However, it does not clarify how this aggregated view relates to siblings like get_sleep or get_heart_rate, which appear to return overlapping data at finer granularity.

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 metric list implicitly signals the aggregated daily scope, which hints at when this is preferable to the granular get_sleep/get_heart_rate siblings. But there is no explicit when-to-use or when-not-to-use guidance, and nothing states that an empty date range is acceptable or what the defaults do.

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

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 does disclose genuinely useful behavior — local-timezone ISO timestamps, bucket averaging, and bucket_minutes=0 meaning raw — but says nothing about permissions, data volume, rate limits, or pagination.

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 telegraphic sentences with zero filler, front-loading the resource and its range scoping. Slightly under-specified rather than bloated.

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?

An output schema exists, so return values need not be described. However, for a 3-parameter tool with 0% schema coverage and no annotations, the description leaves meaningful gaps in parameter semantics and usage routing.

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%, so the description must compensate. It explains bucket_minutes (=0 for raw, with a default of 5 implied by the schema) and clarifies timezone handling for the timestamps, but leaves start_iso/end_iso inclusive/exclusive semantics and format details unstated.

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+resource: raw HR samples over a timestamp range, with bucketing behavior. It distinguishes itself from aggregation-oriented siblings like get_daily, though it never names them 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?

No when-to-use guidance, no mention of prerequisites, and no routing to alternatives such as get_daily for aggregated views. The agent must infer that 'raw' implies low-level granularity.

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

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

With no annotations, the description carries the full behavioral burden, yet it discloses almost nothing: no mention of auth requirements, cost, whether it performs writes or triggers a sync, or how 'days' shapes the output. The only behavioral hint is the Markdown output format, and the output schema already covers the return shape.

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?

A single front-loaded line with no filler; every token names a section of the report. It is efficient, though so compressed that it reads as a fragment rather than a directive.

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?

An output schema exists, so return values need not be explained, but the description still omits the purpose of the days parameter and any routing guidance versus siblings. For a tool with one documented-only-in-schema input, that leaves meaningful 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% for the single 'days' parameter (default 14), and the description never explains it. Mentioning '7-day means' arguably hints at a fixed window inside the report, but the relationship to the days argument is left entirely unstated.

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 the resource (a report) and enumerates its contents (today's card, daily table, workouts, 7-day means), which distinguishes it from siblings like get_daily and get_workouts that return single data streams. However it is a noun fragment with no explicit verb, so the 'what it does' is inferred rather than stated.

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?

No when-to-use guidance at all. It never says to prefer this over get_daily/get_workouts when a consolidated digest is wanted, nor does it name any alternative or exclusion. The agent must guess its place among eight siblings.

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

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

No annotations exist, so the description carries the burden. It does disclose the shape of the returned content, including the useful nuance that two specific tables get column lists, but it says nothing about safety, permissions, or side effects (a reader must assume it is a harmless read). Adequate but incomplete for a zero-annotation tool.

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?

One sentence, front-loaded with the primary output (DDL statements) and appended with the secondary detail (column lists). Every clause earns its place.

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?

An output schema exists, so return-value description is not strictly required, and the description already covers it. What remains missing is any link to the workflow (call this before run_sql), which would make it complete for a schema-introspection tool.

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?

The tool takes no parameters, so there is no parameter meaning to convey and the baseline of 4 applies.

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 concretely states what the tool returns: CREATE TABLE statements for every table plus column lists for daily and workout_metrics. That is more specific than a generic 'get schema', but it never distinguishes itself from schema-related siblings like run_sql or get_report, which is the only thing keeping it from 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?

There is no when-to-use guidance. An agent reading only this description is not told that this is the tool to call before run_sql, nor when the column lists are preferable to the full DDL. Usage is left entirely to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no statement that this is a read-only query, no windowing/pagination behavior, no note that 'days' defaults to 14. Without annotations, the near-total absence of behavioral context is a real gap.

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?

It is a single short sentence with no filler, so it is efficient, but it is under-specified rather than genuinely concise. There is no front-loaded statement of purpose for the field list to elaborate on.

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?

An output schema already exists, so enumerating returned metrics is largely redundant, while the actually useful information ('days' semantics, default window, read-only nature) is missing. For a tool with a parameter and no annotations, the description is too thin to call it complete.

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?

The single parameter 'days' has 0% schema description coverage and a default of 14 that is never surfaced in the description. The description does not mention the parameter at all, so an agent gets no meaning for the time-range control beyond the bare name.

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 is a noun fragment listing returned fields ('Sleep sessions with stage minutes, efficiency, need, performance, debt, consistency') rather than a verb+resource statement. An agent can infer retrieval of sleep data, but the fragment never says what the tool does or over what scope. It also gives no differentiation from siblings like get_daily or get_report.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternative tools. Siblings such as get_daily, get_heart_rate, and get_report plausibly overlap with sleep data, yet the description never routes the agent between them.

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

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

With no annotations provided, the description carries the full behavioral burden, yet it only lists output field names. It says nothing about read-only nature, permissions, rate limits, aggregation behavior, or whether workouts must be synced first (a sync sibling exists).

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?

It is a single terse fragment with no wasted words, so length is fine. However, it is under-specified rather than concise, and the informational content is not front-loaded around the tool's purpose.

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?

An output schema exists, so return values need not be re-explained, but the description omits the temporal scope that the 'days' parameter implies, making the tool's operating context incomplete. For a parameterized retrieval tool with zero annotation coverage, key context is missing.

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 never mentions the sole 'days' parameter, its default of 30, or how the lookback window affects results. The field list adds no meaning about the input, leaving the parameter entirely undocumented.

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 the resource (workout metrics) and enumerates the returned fields, but contains no verb and reads as a fragment rather than stating what the tool does. It does not distinguish itself from siblings like get_daily or get_heart_rate, which also return health metrics.

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?

There is no when-to-use guidance, no mention of the default 30-day window, and no routing vs alternatives such as get_daily or get_heart_rate. The agent gets no signal about the conditions under which this tool is the right choice.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the most important trait — read-only execution — but says nothing about result-size limits, timeouts, whether writes/DDL are rejected, or what happens on error.

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, zero filler, with the read-only constraint and the prerequisite front-loaded before any detail.

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?

An output schema exists, so return values needn't be described, and the read-only contract plus the get_schema prerequisite cover the essentials for a one-parameter tool. Only query-dialect and execution-limit context is missing.

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 'query' parameter has no description, so the schema adds nothing. The description partially compensates by implying the target database and that only read-oriented SQL is valid, but gives no syntax, dialect, or dialect-specific constraints.

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+resource ('SQL against the vitals db') and constrains the operation to read-only, which cleanly separates it from the predefined getters like get_daily and get_heart_rate. It doesn't explicitly name those siblings as alternatives, but the purpose is 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?

'Use get_schema first' gives a concrete prerequisite and names a sibling tool by name, which is real routing guidance. It stops short of saying when to prefer run_sql over the fixed query tools (get_daily, get_workouts), so no explicit when/when-not distinction.

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

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

With no annotations, the description carries the full disclosure burden. It usefully reveals that reports/latest.md is overwritten and that data is read from an inbox export, which hints at destructive/state-changing behavior, but it omits permissions, idempotency, and what happens on failure or when the inbox is empty.

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?

One sentence, fully front-loaded with the action sequence and end target. Every clause earns its place with no filler.

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?

An output schema exists, so return values need not be explained, and a 0-param tool has no argument gaps. However, as a mutation with no annotations, the description should say more about the write target's lifecycle, error conditions, or required access, leaving a meaningful gap.

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?

The tool takes zero parameters, so per the baseline there is nothing for the description to document. The schema already states this fully, and the description correctly focuses on behavior rather than arguments.

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 uses three precise verbs (ingest, recompute, rewrite) against concrete artifacts (inbox export, metrics, reports/latest.md), so an agent immediately knows this is the pipeline that turns the newest export into refreshed reports. It does not name or contrast itself with any sibling, but the write-oriented pipeline is unmistakably distinct from the read-only get_* siblings.

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?

There is no stated condition for when to call this versus the read tools, and no prerequisites, ordering, or exclusions are given. The only implicit signal is that it is the sole mutating tool among the siblings, which the agent must infer.

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