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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description goes beyond that by spelling out the information returned (sync/analysis recency, row counts, wear days, login age), which is meaningful context given there is no output schema.

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, the content list first and the imperative 'Call this first' last, with no filler. 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?

With no parameters, no output schema, and annotations covering the read-only profile, the description carries the remaining burden by describing the return contents and the recommended call order. Nothing an agent needs to invoke it correctly 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?

The tool takes zero parameters, which is the baseline-4 case; there are no argument semantics to clarify. The description correctly implies a no-input diagnostic call rather than suggesting any configuration.

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 enumerates exactly what the tool reports — last sync and analysis, row counts, wear days, and Google login age — so an agent knows it is a data-freshness/diagnostics read. It lacks an explicit verb and never names a sibling, but 'Call this first' signals its role as the entry point relative to tools like get_overview or refresh_data.

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?

'Call this first' gives explicit sequencing guidance that most sibling tools lack, telling the agent when to reach for this tool. It stops short of naming alternatives or a when-not condition, so it is clear context rather than full routing logic.

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?

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only a hint about the payload (tables, views, their columns and purposes) and says nothing about scope, filtering, or size of the returned schema.

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 compact phrase with no waste and the query_sql relationship front-loaded at the end. It is terse to the point of being a label rather than a sentence, but nothing is 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 no-parameter, read-only introspection tool with no output schema, the description does say what comes back (tables and views with columns and purposes) and how it relates to query_sql. Only the return format and coverage limits remain unspecified.

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 there is nothing for the description to disambiguate; the baseline for a 0-param tool applies. No parameter-level expectations are created.

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 fragment names the resource (tables and views, with columns and purposes) and implicitly the action via the tool name. It differentiates itself from siblings by tying directly to query_sql, though it never states an explicit verb like 'describe' or 'list'.

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?

'for query_sql' implies the workflow (inspect the schema before or while writing SQL), but it never says when to call this versus just running query_sql blind, nor any prerequisites. Usage is implied rather than stated.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine behavioral context: the default 7-day window, that 'end' defaults to today, and that days cannot be combined with start. It says nothing about pagination, volume, or resolution of the returned data, so it is helpful but not rich.

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?

Front-loaded with the returned data, then the windowing rules, in about three compact lines with no filler. The metric list is dense but every item is informative; structure is slightly terse rather than padded.

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 3-parameter read-only tool with no output schema and no annotations beyond the safety hints, the description covers the data domain, the default window, and the parameter interactions. The missing date format for start/end is the one thing an agent would still have to guess at.

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 carry the load, and it largely does: it defines the default window (7 days), the semantics of days=N (last N days ending at end), the default for end (today), and the mutual exclusion with start. The only gap is the expected format of the start/end strings, which is left unspecified.

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?

Names the specific resource set it returns (steps, brisk/zone minutes, sedentary hours, strength, weight, workouts, weigh-ins), which lets an agent distinguish it from get_sleep, get_running and get_journal without opening the schema. It lacks an explicit verb and never names those siblings, so differentiation is inferred from content 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?

The description gives real guidance on how to call it ('Default 7 days', 'Or pass days=N ... not with start'), but that is intra-parameter guidance, not tool-selection guidance. It never says when to prefer this over get_overview, get_trends, or get_sleep, so the agent must infer the choice from the returned metrics.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered without the description. The description does add return-shape context beyond annotations (range, components, levers, missing inputs, trend), which is genuinely useful for a tool with no output schema. It still omits date format, timezone, and behavior when the date is omitted.

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 compact sentence with the retrieval rule front-loaded before the colon-delimited list of outputs. No filler, though the fragment style is terse to the point of being slightly cryptic.

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 present, enumerating the return contents (range, components, levers, missing inputs, trend) is the right move and largely discharges that burden. What remains missing for a one-param metric tool is the date acceptance format and the default-when-omitted 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?

Schema coverage is 0% and the single 'date' parameter has no description, so the burden falls on the description. 'On or before the date' usefully establishes that the date is an upper bound rather than an exact-match filter, but the expected format and the null/default behavior remain 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 resource ('body age') and a precise retrieval semantic ('latest ... on or before the date'), which is enough to tell it apart from the other get_* metric tools. It stops short of naming any sibling for comparison, so it sits at a clear-but-undifferentiated 4.

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 statement of when this is preferable to get_trends or get_overview, and no conditions or prerequisites. Usage is only implied by the resource name.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior: results are sorted overdue-first, which is not derivable from the schema. It says nothing about limits, pagination, or result volume.

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?

Very compact and front-loaded — the ordering rule leads, followed by parameter semantics. The telegraphic fragments ('status: ... or None for every note') are terse but each clause carries information, 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?

With no output schema and only two optional parameters, the description covers inputs well, but it omits the return shape (fields on a note) and any result-limit behavior, which an agent would want before calling.

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 carry the load, and it does: it enumerates status values (active|done|dropped) plus None-for-all, and defines due_by as YYYY-MM-DD filtering on review_on <= due_by. The only gap is that it doesn't state matching semantics (exact status equality) explicitly.

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 the resource (coach notes) and its ordering behavior (overdue first), so the agent knows this is a read of coach-note records. It doesn't explicitly name the write siblings (save_coach_note / update_coach_note), but the get/save distinction is inferable from the names.

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 condition for choosing this over get_journal or get_trends, and no stated prerequisites. The description only documents parameters, leaving routing entirely to the agent.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only that the tool surfaces citation/DOI/finding content, but says nothing about batch lookup behavior, what happens with invalid or unknown ids, or cardinality of the result set. Modest added value over the annotations.

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 tight fragment with no filler, and the returned fields are front-loaded. It is under-specified rather than padded, and the missing verb makes the sentence slightly harder to parse than a well-formed clause would be.

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, so the description carries the burden of explaining what comes back – it does name the returned fields (citation, DOI, finding). However, it omits where valid ids originate and any error or empty-result behavior, leaving the lookup workflow only partially specified for a one-parameter retrieval 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?

Schema description coverage is 0% for the single 'ids' array, so the description is the only source of meaning and it gives just the semantic anchor 'evidence ids attached to scores and insights'. It does not clarify the id format, whether ids are opaque strings, or how many can be passed. This partially compensates for the schema gap but leaves format ambiguity.

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 precise payload returned – 'Citation, DOI and finding' – and the key that retrieves it, 'evidence ids attached to scores and insights'. That is enough for an agent to know this is a lookup for evidence records behind scores/insights. It lacks an explicit verb and does not reference any sibling, but no sibling returns evidence metadata, so differentiation is implicit.

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 statement, no mention of where the required 'evidence ids' come from, and no alternatives or exclusions. The phrase 'attached to scores and insights' hints at provenance but never tells the agent when to call this versus get_overview or query_sql.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral defaults (7-day window, end defaults to today, exclusivity with start) but says nothing about return shape, pagination, or empty-range behavior, so it stays at an adequate level.

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 default behavior is front-loaded before the alternative mode. The phrasing is slightly telegraphic ('not with start'), which costs a little clarity but keeps it tight.

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 3-optional-parameter read tool with no output schema, the description covers the parameter interaction model but leaves the date-string format and the returned entry fields unspecified. It is complete enough to attempt a call, but not to call confidently on the first try.

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 carry all parameter meaning, and it does explain the roles of days, end, and start plus their default/exclusion logic. It never states the accepted date format for start/end, which is the most critical missing detail given the null-schema parameters.

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 ('Journal entries') and the scope (a date range, defaulting to 7 days), so an agent can tell it reads journal data rather than writing it. It does not explicitly distinguish itself from siblings like log_journal or get_coach_notes, but the resource noun is distinctive enough to avoid confusion.

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 real usage rules for the parameters — default 7 days, or days=N ending at end (default today), and 'not with start' marking a mutual exclusion. However, it offers no guidance on when to choose this tool over sibling read tools, so usage context is only partially covered.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety profile is covered. The description goes beyond them by disclosing the return composition (scores with confidence, findings, safety alerts first, key metrics), which is genuinely useful output-shaping context for a tool with no output schema. It stops short of describing edge cases such as missing data or empty days.

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 telegraphic sentence with zero filler, and the highest-value facts (what it returns, default behavior) come first. The fragment style is slightly terse but every clause carries information.

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-optional-param read-only tool with annotations and no output schema, the description covers the essentials: what comes back and that today is the default. It omits the date input format and any mention of behavior on empty/missing days, which an agent would need to call 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?

Schema coverage is 0%, so the description must compensate for the single undocumented 'date' parameter. 'Default today' is valuable because it resolves the schema's ambiguous default of null into concrete behavior, but it never states the accepted date format, so the parameter is only partially explained.

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?

Names a concrete resource set: one day's scores with confidence, findings, safety alerts, and key metrics, so an agent can tell this is a daily dashboard/overview rather than a single-domain tool. The verb is only implied by the tool name, and differentiation from siblings like get_evidence or get_trends is left to inference, but the content scope is specific enough to distinguish it.

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 only usage signal is 'Default today,' which concerns the date parameter rather than when to choose this tool. It never states when to prefer it over get_trends, get_evidence, or get_sleep, nor any prerequisites or exclusions, leaving selection 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context about the default window and the days-vs-start exclusivity, but says nothing about result limits, truncation, or empty-data behavior when no race is configured beyond the parenthetical.

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?

Front-loaded with what is returned, then the windowing rules, in three short sentences with no filler. The telegraphic style is efficient, though the final clause is compressed enough to require a second read.

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, the description does the work of characterizing the return payload (distance, pace, HR zones, spike flags, race plan status) and the default time window. For a 3-param read-only tool this is nearly sufficient; only date-format and result-size details are absent.

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 carry the parameter burden; it does explain that days selects the last N days ending at end (default today) and that start is mutually exclusive with days. It omits the accepted date format for start/end, which is the only real gap.

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 resource (running) and enumerates the returned content (distance, pace, HR zones, spike flags, race plan status), which clearly separates it from siblings like get_sleep or get_activity. It does not explicitly name an alternative sibling, so it stops short of a 5 under the differentiation criterion.

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 concrete default (30 days) and an explicit alternative form (days=N ending at end), including the exclusion 'not with start'. That is real when-to-use guidance for the parameter modes, though it offers no guidance on when to prefer this tool over adjacent tools such as get_trends or get_activity.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds genuine domain context, explaining what the payload contains (bed/wake local times, stages, efficiency, naps, death, and the SRI scale of -100..100 where 100 means identical daily timing). It stops short of describing authentication, pagination, or timezone handling.

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 sentences, front-loaded with what you get and followed by how to scope it. The heavy parentheticals are dense but each clause carries information; nothing is 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?

With no output schema, the description correctly spends its space describing the returned fields and the SRI semantics, and it documents the default window and parameter interaction. Complete enough to call correctly, with only the date-format detail 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%, so the description carries the burden and does well: it explains days=N, that the window ends at end (default today), the 7-day default, and the start/days mutual exclusion. It does not specify the accepted date format for start or end, which is the remaining gap.

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 (sleep nights, scores, subscores, debt, SRI) and enumerates the data returned, so an agent can distinguish it from siblings like get_activity or get_trends. It lacks an explicit verb, but the scope is clear and concrete.

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 real usage rules for the parameters — default 7 days, days=N ending at end, and that days must not be combined with start — but says nothing about when to prefer this tool over sibling tools such as get_overview or get_trends. Usage is implied by the default window rather than stated vs alternatives.

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?

Annotations already declare readOnlyHint and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior: unknown metric names return the full list, the default window, the 366-day cap, and that today is the default end. It still omits return shape details beyond 'baseline/band' and any rate or permission notes.

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?

Dense and front-loaded: the output shape leads, then the acceptable values, then windowing rules. The long metric enumeration is necessary given the absent enum in the schema; little is wasted, though the run-on windowing sentence is slightly hard to parse.

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 4-param read tool with no output schema, the description supplies the enumerable value sets, windowing semantics, and default behavior an agent needs. The main shortfall is that the return structure is only gestured at ('baseline/band'), with no explanation of fields.

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 carry the load, and it largely does: it lists valid metric and score names, explains days=N vs start exclusivity, sets end's default, and states the default 30-day and max 366 windows. The only gap is the date string format for start/end.

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 output shape ('Daily series with baseline/band') and enumerates the metrics and score families it covers (rhr, hrv_7d, score:recovery, etc.). Clear what it does, but it never names or contrasts with sibling readers like get_sleep, get_activity, or get_overview, so differentiation is left 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?

Usage is implied through the parameter guidance ('Default last 30 days; max 366', 'days=N ... not with start'), which tells the agent how to scope a query but not when this tool beats get_overview or get_sleep. No explicit when-not or 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?

The annotation readOnlyHint=false already tells the agent this is a write, and the description is consistent with that. 'Local only' adds genuine behavioral context (data is not synced remotely), but there is no mention of what happens on a repeat call for the same date, permission needs, or validation behavior.

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 dense sentence front-loads the core action and the field/range pairs, with 'Local only' as a short trailing clarifier. No wasted words and nothing buried.

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 8-parameter mutation tool with no output schema and only a readOnlyHint, the description covers most fields with value ranges and flags local storage. The remaining gap is the date parameter's semantics (default behavior, one entry per day?) and conflict/overwrite 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?

With 0% schema description coverage across 8 parameters, the description carries the full burden, and it largely does: it supplies ranges for feeling/energy (1-5), soreness/session_rpe (0-10), and alcohol units (0-50) and names illness and notes. Only 'date' is left undocumented in both schema and description.

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 ('Log') plus the resource and enumerates the subjective fields being captured, so the agent knows exactly what the tool writes. It does not explicitly differentiate itself from the sibling get_journal, though the write-vs-read contrast in the verb makes the split inferable.

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 the verb and the field list ('Log how the user feels'), but the description never says when to reach for this versus get_journal, nor whether a journal entry already exists for a date. No prerequisites or exclusions are given.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds concrete operational limits beyond them: max 500 rows, 5 s execution, 2000-character truncation of text cells, and single-statement enforcement. Missing only error/timeout failure behavior and whether calling it more than once is rate-limited.

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 dense sentence, front-loaded with the operation and immediately followed by the hard limits. Every clause (row cap, timeout, truncation, date format) earns its place; 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, no-output-schema tool the description supplies the essential constraints an agent needs to avoid rejected or truncated queries. The notable gap is not pointing at describe_schema to learn tables/columns before writing SQL.

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 'sql' parameter has zero schema description, so the description carries the burden and does well: it constrains content to one read-only SELECT and specifies date literals as 'YYYY-MM-DD' strings. It does not document the return columns, but no fixed column set exists for arbitrary SQL.

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 ('Run ONE read-only SELECT on the local database') and scopes it tightly to a single statement. It is clearly the arbitrary-SQL escape hatch, though it never names or contrasts itself with the many domain getters in the sibling list.

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 explicit when-to-use guidance and no mention of alternatives such as the domain-specific getters (get_sleep, get_activity, get_trends) or describe_schema for discovering table/column names. The agent must infer that this is the ad-hoc fallback rather than call a purpose-built sibling.

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?

Annotations only declare readOnlyHint=false, so the description usefully adds that this triggers a sync plus a downstream analysis and can take up to a few minutes. However it doesn't say whether repeat calls are rate-limited, whether it blocks, or what the side effects on existing data are.

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 short sentence front-loads the action, and the parenthetical adds the crucial consequence and latency without waste. 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?

With zero parameters and no output schema, the description only needs to convey behavior, and it covers the action, its downstream effect, and duration. It could say more about whether the sync is idempotent or how long results stay fresh.

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 the baseline is 4. There is nothing for the description to disambiguate on the input side.

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 (Sync) and resource (new data from Google) with the follow-on effect (analysis runs). It is clear what the tool does, though it doesn't explicitly contrast itself with the sibling data_status, which an agent might otherwise confuse it with.

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 phrase 'now' implies you call this when you want fresh data, but there is no explicit when-to-use versus data_status or query_sql, and no exclusion or prerequisite guidance. Usage is only implied.

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?

The 'Local only' note is genuinely useful behavioral context beyond readOnlyHint=false: it tells the agent this write is not synced/remote. However the description is silent on repeat-write behavior, whether review_on schedules a future reminder, and what the call returns.

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 sentence with the enum inline as a parenthetical; no filler. The trailing 'Local only' is terse but earns its place as real, non-schema information.

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 3-parameter mutation tool with no output schema and zero schema description coverage, the definition is thin: semantics of review_on, return behavior, and the boundary with update_coach_note are all 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%, so the description carries the full burden. It usefully enumerates the valid kind values (plan|target|observation), which the schema leaves as an unconstrained string, but text and especially review_on are left completely undefined.

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 ('Remember' = persist a note) and names the concrete record types it can hold (plan, weekly target, observation). Siblings like get_coach_notes and update_coach_note are not addressed, so the agent must infer that this is the create path rather than having it 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?

'Remember an agreed plan, weekly target or observation' implies the capture context, but nothing says when to choose this over update_coach_note (edit an existing note) or log_journal (a different journaling sibling). Usage is implied rather than routed.

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?

readOnlyHint=false only tells the agent this mutates; the description goes further by disclosing the analysis re-run side effect and, importantly, the destructive clearing semantics of the value "none" (which fields get wiped). That is real behavioral context beyond the annotation, though it omits permissions/error behavior.

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?

Front-loaded with the core action, then a dense but necessary key reference, then the clearing rule. Every item earns its place, though the key enumeration is compact to the point of being list-like.

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 2-param mutation tool with no output schema and no schema descriptions, the description supplies the missing parameter semantics and clearing behavior. It stops short of explaining return values or what happens on invalid keys, but is otherwise sufficient to call the tool 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?

With 0% schema description coverage, the description carries the full burden and does so well: it enumerates every valid key and pins down value formats (race_date as YYYY-MM-DD, units as metric/imperial, timezone as an IANA name, goals as a list of strings, hrmax_override as number-or-numeric-string) plus the special "none" value. This adds substantial meaning the generic key/value schema lacks.

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+resource ("Change a profile value") and adds a distinctive behavioral consequence ("re-run the analysis"). Enumerating the valid keys makes the tool's scope unambiguous and clearly separates it from the get_*/log_* 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?

It lists valid keys and formats, which implies usage, but never says when to reach for this tool versus the other profile/data tools or what prerequisites exist. The usage is inferable but not stated.

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?

The only annotation is readOnlyHint=false, so the bar is low. The description confirms mutation and lists which fields change, which adds some value, but it says nothing about partial-update semantics (are unset fields left untouched?), return behavior, or whether marking 'done/dropped' is reversible.

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 compact sentence with the primary mutation front-loaded and no filler. It is appropriately sized, though it borders on under-specification for a 4-parameter mutation 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?

For a mutation tool with 0% schema coverage, no output schema, and a non-read-only annotation, the definition is thin. It omits partial-update behavior, permission/ownership requirements, and any indication of what the call returns or how errors surface.

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 only partially does. It explains that text and review_on are editable and gives the meaningful status values 'done/dropped' (absent as an enum in the schema), but leaves 'id' and the date format of review_on unspecified.

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?

It names a specific verb+resource (update a coach note) and enumerates the mutable aspects (status done/dropped, text, review date). It is distinguishable from siblings like save_coach_note (create) and get_coach_notes (read), though it never names an alternative 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 when-to-use or when-not-to-use guidance, and no alternative tool is referenced even though save_coach_note and get_coach_notes exist. Usage is only implicitly inferable from the operation description.

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