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

With no annotations, the description carries the full burden and does useful work: it discloses the returned statistics (mean/median/n, delta %, Cohen's d, plain verdict) and the default exclusion of travel days. What it never states is that this is a read-only, side-effect-free operation, nor whether the comparison itself has any prerequisites such as ingested data or configured periods.

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?

Three dense sentences, front-loaded with the core action and with no filler. The parenthetical about period_a/period_b becoming labels is slightly compressed and requires a second read, but every sentence carries information an agent needs.

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?

The description substitutes well for the absent output schema by enumerating return values, and it explains default behavior. However, for a six-parameter tool with zero schema documentation, omitting the metrics filter and never saying what valid period names look like leaves the definition only minimally sufficient.

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 it does for most inputs: a_range/b_range get an explicit format example ('2025-03-01..2025-03-31'), period_a/period_b are explained as labels in ad hoc mode, and the default of the first two named periods is given. The metrics parameter is never mentioned at all, leaving one of six inputs entirely undocumented, and the travel-day note is not tied to the home_only flag by 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 first sentence names a specific verb and resource (compare two periods) and the rest clarifies how periods are selected. It references set_periods as the source of named periods, which helps position it among siblings, but it does not distinguish itself from monthly_trends or rolling_baseline, which are plausible alternatives for time-based comparison.

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?

It clearly lays out the two invocation modes — named periods from set_periods (with the default being the first two) or ad hoc ranges — which is exactly the decision an agent must make before calling. It stops short of saying when this tool should be preferred over monthly_trends or rolling_baseline, so there is no true alternative routing.

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 burden, and it does disclose one real behavioral trait: the payload is precomputed (`signals`, `trips`), signaling derived values that may lag the underlying data. It does not explicitly confirm this is a read-only operation, nor does it warn about payload size or latency for an aggregate endpoint.

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 compact sentences with the payload scope front-loaded and no filler. The trailing instruction is slightly cryptic – "the story" is never defined in the tool surface – which costs it a point.

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?

This is a zero-argument aggregate endpoint with no output schema, so the return shape is invisible until invocation; the description hints at two keys (`signals`, `trips`) but not the rest of the structure. Reasonably adequate for a simple no-param call, but thin given the absent output contract.

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 schema has zero parameters and 100% coverage, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-argument tool.

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 identifies the resource precisely as the aggregate of everything the dashboard renders, which implicitly distinguishes it from piecemeal siblings like `overview`, `trips`, and `monthly_trends`. It lacks an explicit verb ("returns"), and it does not address the naming collision where `trips` is both a sibling tool and a field inside this payload.

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?

"Read this before writing the story" gives an implied sequencing hint – call this first when composing narrative output. However, it never states alternatives or when NOT to use it, so an agent cannot tell from the description alone whether this supersedes `overview` / `monthly_trends` or merely wraps 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, the description carries the full behavioral burden. It discloses the detection basis (contiguous UTC-offset runs) and output categories (homes and trips), but it does not explicitly confirm read-only behavior, non-mutation, or data-access constraints.

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 short, front-loaded, and contains no filler. The first sentence describes the output and the second gives usage, though the phrasing is somewhat dense.

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?

The output schema exists, so return-value details need not be in the description. However, the description leaves min_days unexplained and, without annotations, does not cover behavioral constraints or alternatives sufficiently for a fully self-contained definition.

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 only parameter, min_days, has 0% schema description coverage and is not mentioned in the description. Its name is fairly intuitive, but the definition does not explain how the threshold affects detected runs or the default of 3.

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 states a concrete output: a timeline of contiguous UTC-offset runs split into homes and trips. It is specific enough to understand the resource, but it does not explicitly distinguish this tool from sibling tools such as trips or set_periods.

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 sentence 'Use it to suggest periods (e.g. a move)' gives a clear use case for the tool. It does not state when not to use it, prerequisites, or alternatives, so it falls short of full routing guidance.

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 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.

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

With no annotations, the description does real work: it discloses the destructive replace-the-old-database behavior, the ~10 second cost, and the re-run trigger. It omits failure/validation behavior (bad zip, partial import, whether old data survives a failed load), which matters for an unannotated destructive write.

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?

Three short sentences, front-loaded with the action and input format, followed by cost and trigger. Nothing redundant.

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 single-parameter destructive tool with no annotations and no output schema, the description covers what it does, its cost, and when to call it. Missing are return/verification signals and error handling, which would complete the picture.

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 'path' parameter has no description, so the description must compensate. It does, clarifying the expected input shapes (.zip file or extracted folder), which the bare 'string' schema does not convey. Path resolution (absolute vs relative) remains 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 (load/ingest) and a specific resource (Samsung Health export as .zip or extracted folder) with the destination (local database). Distinct from every sibling, which are read-only analytics/query tools.

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?

Gives a clear trigger condition: 'Re-run whenever the user downloads a fresh export.' No explicit alternatives or exclusions are named, but no sibling tool overlaps with ingestion, so the gap is minor.

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 burden. It discloses relevant behavior: output includes mom_pct, dates use YYYY-MM-DD, and home_only removes travel days. It does not state that the operation is read-only, whether start/end are inclusive, or what happens when dates are omitted, leaving meaningful behavioral gaps for an aggregation 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?

The description is short and front-loaded, leading with the output shape before parameter quirks. Each sentence adds information; it could be slightly more organized by grouping the date-format note with start/end, but there is no wasted text.

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 the description covers key quirks like mom_pct, home_only, and metric defaults. But with no annotations and 0% schema coverage, gaps remain around read-only status, date-boundary behavior, and when to use it versus siblings like compare_periods and rolling_baseline.

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. It explains home_only semantics, the date format for start/end, and that metrics default to a core set with overview() for valid keys. It does not clarify omission behavior for start/end (e.g., whether null means all available history) or whether date bounds are inclusive, so coverage is partial.

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 states a specific resource and computation: monthly averages per metric with month-over-month percent change (mom_pct). It is clear what the tool produces. It does not explicitly distinguish itself from siblings like compare_periods or rolling_baseline, which keeps 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?

It gives useful context for two parameters: home_only=True drops travel days, and metrics default to the core set with overview() as the reference for all keys. However, it does not say when to choose this tool over compare_periods, rolling_baseline, or overview, nor does it describe exclusion cases.

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. It lists some content the tool surfaces, but says nothing about whether it is read-only, whether it is cheap or expensive, what triggers it, or how results are shaped. For a zero-annotation, zero-output-schema tool this is thin.

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 very short with no padding, but it is a telegraphic fragment rather than a front-loaded statement of what the tool does. Brevity here comes at the cost of clarity rather than from efficiency.

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 annotations, no output schema, and no parameters, the description is the only signal available and it delivers a partial field list without stating the tool's action or the conditions for using it. An agent would have to guess that this is an orientation/metadata call.

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 (0 params, 0 required), so the schema baseline of 4 applies; there is nothing for the description to disambiguate. It does not mislead about inputs.

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-phrase inventory ("Date range, data coverage per metric, available metrics and the periods being compared") with no verb, so it never explicitly says the tool returns a dataset-level overview. It does, however, imply a metadata/summary role that distinguishes it from analytical siblings like monthly_trends or compare_periods. Purpose is inferable but not 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?

There is no statement of when to call this versus alternatives — notably `schema`, `compare_periods`, or `dashboard_payload`, all of which could plausibly serve a similar orientation role. The agent must infer that this is a 'call first to understand the data' tool.

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 burden and does well: it states that the tool returns a file path and when to use return_html for clients that cannot read local files. It adds guardrails such as grounding actions in payload numbers and only using confirmed callouts/trip labels, though it omits file overwrite behavior or file location details.

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 purpose is front-loaded in the first sentence, followed by compact parameter-specific guidance and return behavior. Every sentence adds useful constraints or examples, and there is no redundant 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?

For a seven-parameter render tool with no output schema and no annotations, the description is fairly complete: it explains parameter formats, data grounding rules, and return behavior. It could be richer about where the file is written and whether existing files are overwritten, but the core call contract is clear.

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 documents all seven parameters, including exact action count and fields, example shapes for callouts and trip_labels, and the purpose of return_html, adding substantial meaning beyond the bare schema titles.

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 first sentence states a specific verb and resource: render the single-file dashboard with the story from the payload. It is clearly distinct from data-query siblings such as dashboard_payload, though it does not explicitly name the alternative tool.

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 this is used after composing a story from the payload, and it gives a conditional for return_html when the client cannot read local files. It does not explicitly state when to use this versus dashboard_payload or other output tools.

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 burden, and it does add useful behavioral meaning by explaining the z-score threshold for unusual values. However, it does not state whether the tool is read-only, what data source it uses, or any access constraints, leaving operational transparency incomplete.

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 two short sentences with no wasted language, and the core concept plus the interpretation threshold are front-loaded. It is appropriately sized for a simple analytics tool.

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?

The tool is simple and has an output schema, so the description need not explain return shape. Still, for a two-parameter tool with 0% schema description coverage and no annotations, the description leaves important invocation details and sibling differentiation unaddressed.

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 explain the two parameters. It only vaguely implies a daily metric and a trailing baseline window, without clarifying what `metric` accepts, what `window_days` controls, or what the defaults mean.

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 clearly communicates that the tool computes each day's value against a personal trailing baseline and returns a z-score. It does not explicitly distinguish this from siblings such as monthly_trends or compare_periods, so it stops short of 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?

The description gives an interpretation rule for the output (|z| > 2 is unusual), but it does not say when to use this tool versus alternatives like monthly_trends or compare_periods. There are no exclusions or context-setting instructions for selecting this tool.

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 state the operation is read-only, which is the single most important safety fact for a SQL tool. However it is silent on row limits, the default limit of 200, timeouts, error behavior on invalid SQL, and whether any statement other than SELECT is rejected.

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 waste, with the read-only constraint and the main table front-loaded before the supporting table list. Every clause gives the agent information it could not get from the schema.

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 explanation is unnecessary, and the table inventory covers the hardest part of using a raw-SQL tool. The remaining gap is the undocumented `limit` parameter and the absence of routing guidance against the specialized siblings.

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 partially does by enumerating the available tables, which is essential semantic context for constructing the `query` argument. It says nothing at all about the `limit` parameter (its default 200, whether it can be raised, or what it does to wrapped queries), leaving half the surface 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?

States a specific verb+resource ('Run a read-only DuckDB query') and immediately names the primary table plus six secondary tables, which tells an agent exactly what domain it is querying. It is distinguishable from the analytics siblings (overview, monthly_trends, trips), though it never explicitly frames itself as the raw-SQL escape hatch.

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 guidance on when to use raw SQL versus the many purpose-built siblings (overview, sleep_timing, hourly_profile, etc.), and no stated prerequisites, cost, or row-limit warnings. The agent must infer that this is the fallback for questions the specialized tools cannot answer.

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 must carry the behavioral burden. It states the content the tool exposes but does not explicitly confirm read-only behavior, side effects, or whether the result is cached or live schema metadata.

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, front-loaded sentence with no redundant or wasted wording. It communicates the core resource immediately.

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?

Given the low complexity, zero parameters, and lack of an output schema, the description is almost complete. It could add a brief note on return format or usage sequencing, but the essential purpose is present.

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 has zero parameters, so there are no parameter semantics to explain. The baseline score of 4 applies because no additional parameter guidance is needed.

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 identifies the resource clearly: tables and columns available for SQL execution. It also ties the schema to the sibling tool run_sql, though it does not use a direct verb like 'returns' or 'lists' and stops short of full sibling differentiation.

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?

Mentioning 'available to run_sql' implies that this tool should be consulted before writing SQL, but it does not explicitly state when to call it, when not to, or what alternative exists. Usage is inferred rather than prescribed.

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 behavioral burden and does well: it discloses that periods are saved, that an empty end means today, that tz_offsets overrides automatic travel detection, and that [] restores the 90-day default. It leaves out overwrite semantics, return behavior, and error conditions, so it is not fully complete.

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 front-loaded with the action, followed by a concrete example and then the key default/reset behaviors. Every sentence adds useful information, and there is 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?

For a one-parameter configuration tool with no output schema and no annotations, the description supplies the essential examples, defaults, and reset behavior. Minor gaps remain around whether saved periods overwrite prior periods and whether tz_offsets belongs inside each period object, but an agent has enough to call it correctly.

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 schema only shows a generic periods array, so the description must compensate. It does so by showing the expected object fields (name, start, end), explaining the empty-end default, and documenting optional tz_offsets and the reset value. It still does not formally state which fields are required within each period object.

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 states a specific verb and resource: save periods used for comparison. The example makes the intended data shape clear. However, it does not explicitly distinguish this configuration tool from the sibling compare_periods tool, leaving the relationship to be inferred.

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 by 'Save the periods to compare' and by the reset behavior 'Pass [] to go back to the 90-day default.' There is no explicit statement of when to call this versus compare_periods or the dashboard/reporting siblings, and no when-not guidance.

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 must carry the behavioral burden. It usefully defines bedtime consistency as a standard deviation in minutes, but it never states that this is a read/computation, what data is required, or how 'per period' works when the schema exposes no period parameter.

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 one compact, front-loaded sentence with no filler, and the metric list is efficiently presented. It is a fragment rather than a fully structured definition, but it avoids waste.

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 simple one-parameter read tool, listing returned metrics is helpful. Still, with no annotations, no output schema, and no explanation of home_only or period handling, an agent lacks enough context to invoke it confidently.

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 only parameter, home_only, is neither explained nor mentioned, and schema description coverage is 0%. The phrase 'per period' suggests a period input, but no such parameter exists, making the input semantics particularly unclear.

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 sleep metrics reported (bedtime, wake time, sleep hours, split nights, consistency), so the resource is identifiable. However, it is a bare noun phrase with no verb and no boundary against siblings such as overview, monthly_trends, or compare_periods, leaving differentiation to inference.

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 guidance on when to use this tool instead of siblings like overview, monthly_trends, compare_periods, or rolling_baseline. It also gives no prerequisites or exclusions, only an implied scope of sleep timing per period.

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 burden. It usefully discloses the detection method (timezone-based) and comparison baseline (30 home days before each trip), but omits data requirements, permissions, and return structure.

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 efficient sentence with no wasted words and front-loads the core purpose. It could be slightly clearer if the comparison and output clauses were structured separately, but it remains appropriately sized.

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?

The core analysis is described, but important gaps remain: min_days is unexplained, no data prerequisites are stated, and there is no indication of what the response looks like despite having no output schema. An agent would need to infer usage and parameter behavior.

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 only parameter, min_days, has 0% schema description coverage and is never mentioned in the description. The description therefore fails to compensate for the low schema coverage and leaves the parameter's meaning unexplained.

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 states a specific analytical resource: trips detected from phone timezone, each compared to 30 prior home days, with travel effects on steps, sleep, and heart rate. It implicitly distinguishes itself from detect_locations by saying no location data is needed, though it does not name that sibling 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?

There is no guidance on when to use this tool versus alternatives such as detect_locations or other trend tools. It also does not state prerequisites like ingested data or timezone availability.

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 full disclosure burden, and it discloses very little: it does not say what 'per period' means, where periods come from, how the average is computed (mean of daily values? weighted?), what the result looks like, or what happens with missing days. Only the aggregation intent is conveyed.

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 tight sentences with the core operation front-loaded and the use case second; nothing is wasted. It is brief to the point of under-specification rather than verbose.

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 an analytical tool with two undocumented parameters, no annotations, and no output schema, the description leaves key questions open: which periods are used, and what home_only filters. It is not sufficient on its own to call this tool confidently.

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 and it does not. It mentions 'a metric' but never enumerates valid metrics, and the home_only boolean parameter is never mentioned at all despite materially changing the data source.

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 computation (average of a metric) over a specific dimension (weekday Mon..Sun) and scope (per period), which distinguishes it from hourly_profile and monthly_trends. It stops short of naming a sibling explicitly, so it is clear but not maximally differentiated.

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 second sentence gives a concrete analytic use case (weekend effects, Sat/Sun vs Fri/Sat), which is genuine usage context. However, it never states when to prefer this over hourly_profile or monthly_trends, nor any prerequisites such as periods needing to be set.

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. It discloses that results are grouped by month, period, and type, but says nothing about read-only behavior, authentication, pagination, defaults, or how the start/end parameters affect the result set.

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 efficient sentence with no filler and the grouping dimensions are front-loaded. It is appropriately sized, though its terseness contributes to the gaps in parameter and usage guidance rather than compensating for them.

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 leaves start/end semantics, usage context, and basic behavioral expectations unaddressed. For a two-parameter data retrieval tool with no annotations and zero schema description coverage, it is not complete enough to guide reliable invocation.

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 start or end parameters. With two undocumented parameters and no compensating explanation in the description, an agent cannot tell whether they are date bounds, period identifiers, or something else.

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 identifies the resource (recorded exercise sessions) and the grouping dimensions (month, period, type), but it is a noun phrase with no action verb, so it does not explicitly state what the tool does with them. An agent can infer retrieval, but the purpose remains implicit rather than clearly 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?

There is no guidance on when to use this tool versus alternatives such as trips, monthly_trends, or overview. The name and description imply it returns workout data, but no conditions, prerequisites, or exclusions are provided.

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