whatevr

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds real value beyond them: it discloses that per-item names and nutrition are returned, that the shape matches get_today, and that each `recent` item carries an `id` usable with update_log. It does not cover what happens when nothing was logged on that date or how an invalid/future date is handled.

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 what the tool returns, followed by the question it answers and the follow-up action it enables. No filler; the one unusual device (capitalized INCLUDING) is doing real work by flagging that payload detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and mostly meets it by describing included fields and deferring shape to get_today. The reliance on a sibling's documentation is a slight indirection, and edge cases (empty day, bad date) are left unstated, but an agent has enough to call this 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 coverage is 100% — the single `date` parameter is documented with a YYYY-MM-DD regex pattern and format note. The description adds only the natural-language framing ('yesterday / on <date>') and no format, timezone, or boundary semantics beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Everything logged on a specific day') and narrows scope by calling out that food names and nutrition are included. It differentiates from siblings by anchoring the return shape to get_today and by naming update_log as the corrective follow-up.

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 an explicit use case in the user's own words ('what did I eat yesterday / on <date>'), which tells the agent exactly which question routes here. It stops short of an explicit exclusion ('do not use for today — use get_today'), leaving that switch to be inferred from the date parameter and the shape reference.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds genuine value by disclosing what actually comes back (identity fields, health profile, targets, derived metrics), which matters because there is no output schema — though 'derived metrics' stays undefined.

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 a colon-delimited payload list; every element maps to something the caller would want to know. Slightly compressed to the point that 'derived metrics' is opaque, but 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 zero-parameter, read-only profile fetch with no output schema, the description carries the return-value burden and mostly discharges it by enumerating the field groups. The only gap is that the nature of the 'derived metrics' is left 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 the baseline applies; there is no parameter surface the description needs to explain. Nothing in the description misrepresents the no-input contract.

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 resource precisely (the user's own identity: name/handle/email) and enumerates the payload categories it returns — health profile, calorie/macro targets, derived metrics. That is enough to distinguish it from day-scoped siblings like get_today and get_progress, though the verb is only implied by the tool name 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?

Usage is implied by the content: reach for this when you need who the user is or their targets. There is no explicit 'use when' clause, no exclusions, and no mention of the sibling tools that return day-level or progress data, so an agent must infer the boundary itself.

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 destructiveHint=false, so safety is covered. The description adds real behavioral value: it discloses the result is aggregated TOTALS plus a weight trend, not item-level records — a key output characteristic not in 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 front-loaded sentence with no waste; the scope and the sibling caveat are both stated compactly.

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 read-only tool with full schema coverage and annotations handling safety, the description covers what it returns (totals + weight trend) and the key sibling boundary. No output schema exists, but the aggregated nature of the result is conveyed well enough.

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 100%, so days, anchor, and tz_offset_min are all fully documented in the schema. The description adds no parameter-level detail beyond it, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — daily calorie/macro/exercise totals over time plus weight trend — and explicitly distinguishes itself from get_day by noting it omits food item names. An agent can tell it apart from siblings without opening any schema.

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?

Explicitly routes the agent to get_day when food item names are needed, giving a clear condition that selects the alternative. It stops short of a full when-to-use/when-not matrix, but the primary sibling boundary is 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds real value by enumerating what the response contains, including the `recent` sub-structure with names, calories, macros, and ingredients — important since there is no output schema. It does not disclose limits such as how many `recent` items are returned or whether the log is truncated to the current day only.

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 the return payload rather than burying it behind preamble. The parenthetical enumeration is dense but every element names a real output field; only the update_log aside is arguably secondary.

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 carries the burden of explaining return values and does so well. The main residual gap is the absence of any boundary relative to get_day and get_progress, and no note on truncation or history window for the food log.

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?

There is a single optional parameter with 100% schema description coverage, so the schema already fully explains the JS getTimezoneOffset() convention and the fallback behavior. The description contributes nothing about tz_offset_min, making this the baseline 3 by the coverage rule.

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 concretely — today's totals, water, streak, exercises, and item-by-item food log — which is a richer and more specific scope than the bare name suggests. It implicitly contrasts with get_day/get_progress by emphasizing 'Today's complete picture' and 'streak', but never names those siblings, so differentiation is left partially 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 only implied by the scope ('today'), with no explicit statement of when to prefer this over get_day or get_progress. It does provide one valuable routing hint — that `recent` item `id`s feed update_log — but that is a downstream handoff rather than guidance on 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?

Annotations already declare readOnly=false, destructive=false, and openWorld=false, so the mutation profile is known; the description still earns credit for disclosing a non-obvious side effect (explicit nutrition pins totals and collapses the entry into one pre-computed item with no ingredient breakdown). However it never says what comes back from the call (e.g. a log id), which the prescribed update_log follow-up depends on.

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?

Purpose and examples are front-loaded and every sentence carries information, including the nutrition caveat. Slightly dense in the final sentence, which could be tightened, but 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?

Strong for a mutation tool with annotated safety: behavior, parsing quirks, and a remediation path are all present. The one gap is the return contract — the description instructs a follow-up update_log call without stating that an id is returned to make it possible.

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 100% and logged_at/tz_offset_min are already documented in-schema. The description adds real meaning only about `text` — the parser is the app's voice parser, spoken dates are accepted, and explicit nutrition changes how the text is interpreted — but it doesn't tie those behaviors to the parameter explicitly or give syntax/format hints beyond the schema.

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?

A concrete verb and an explicit list of resources (food, drinks, water, exercise, weigh-in), plus four worked examples that make the input shape concrete. It does not, however, differentiate itself from the sibling tools log_exercise / log_water / log_weight, so an agent must infer that this is the natural-language generalist.

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?

Given clear conditions: free-form sentences, spoken dates like 'yesterday', and a specific branch telling the agent to follow up with update_log's `ingredients` array when explicit nutrition is stated. Missing an explicit when-not / prefer-log_water style exclusion against the domain-specific siblings.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the write/safety profile is covered. The description usefully establishes that calories must be user-supplied rather than estimated, but says nothing about whether a new entry is created versus merged, whether a log can be corrected later via update_log, or how validation bounds (20,000 cal, 1,440 min) fail.

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, zero filler, with the primary scope assertion front-loaded before the routing hint. Nothing could be removed without losing 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?

With no output schema the description needn't describe returns, and annotations carry the safety profile, so the remaining burden is modest. However, for a 5-parameter write tool with no units stated for the two numeric required fields and no mention of the update_log relationship, the description is adequate but leaves real gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 60%; activity, logged_at, and tz_offset_min are documented in-schema, so the baseline is 3. The description does not compensate for the undocumented required parameters: it never states that calories_burned is in kcal or that duration_minutes is in minutes, both of which are plausible points of agent error given the 0–20,000 and 1–1,440 bounds.

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 leads with a specific verb and resource ('Log structured exercise') and immediately narrows the scope with the qualifier 'with a known calorie burn.' It also explicitly names the sibling it is not (log_anything), so an agent can distinguish the two without opening either schema.

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 states an explicit when-not condition and the alternative: 'For an ESTIMATED burn from plain text, use log_anything.' The parenthetical example ('30 minute run') shows the exact shape of input that should route elsewhere, which is unambiguous 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?

Annotations already declare this is a non-destructive, closed-world write (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description adds the meaningful default of 1 glass and the 8 fl oz equivalence, but says nothing about whether repeated logs accumulate or replace, or what comes back on success.

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, front-loaded with the action and the two input modes, with the default stated last. No wasted wording.

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 accumulator tool with zero required parameters, an explicit default, and annotations covering the safety profile, this is nearly sufficient. The only real gap is that return behavior and duplicate-entry handling are not described and there is no output schema to fall back on.

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 75%, and the description still adds value beyond it: the 8 fl oz unit conversion, the default of 1 glass when no quantity is given, and the either/or relationship between glasses and amount_fl_oz. It is silent on logged_at and tz_offset_min, which the schema covers on its own.

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 ('Log water') and immediately names the two input modes plus the default. It doesn't explicitly contrast with siblings like log_anything, but the resource name makes the scope unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied (record water intake) and the choice between glasses and amount_fl_oz is spelled out, but there's no explicit guidance on when to prefer log_water over the generic log_anything sibling, nor any exclusions or prerequisites.

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 this is a non-read-only, non-destructive, closed-world write, so the safety profile is covered. The description usefully adds the consequential side effect that the newest reading becomes the current weight and drives calorie targets. However, it is silent on how backdating via logged_at interacts with 'newest reading', and whether a same-day entry replaces an earlier one.

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, zero filler, with the primary effect front-loaded and the downstream consequence in a parenthetical. Nothing redundant with the schema or annotations.

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 no output schema and 4 parameters, the definition covers purpose and the main side effect but leaves the agent without knowledge of what is returned or how re-logging/correcting an existing weigh-in is handled. That is an incomplete picture for a write operation.

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 50%, and the two documented parameters (logged_at, tz_offset_min) are well specified in the schema itself. The description compensates for the largest gap by declaring weight_lb is in pounds, which the schema does not state; only the free-form 'note' parameter goes 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?

States a specific verb (log) plus resource (weigh-in) and immediately disambiguates from siblings like log_water, log_exercise, and log_anything by naming the exact domain concept. The unit ('in pounds') is stated up front, which no other field supplies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: an agent can infer this is the tool for recording a body weight, but nothing says when to prefer update_log for corrections or how log_anything differs. No exclusions or prerequisites 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?

None of the annotations reveal the side effects spelled out here: replacing ingredients recomputes totals, setting top-level numbers rescales the ingredient breakdown proportionally, editing a routine-created log's title or calories mutates the saved routine, and changing logged_time can re-infer the meal. These are exactly the non-obvious mutation consequences an agent needs before calling a destructive 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 mode-selection rule and prerequisite are front-loaded and each sentence carries distinct operational information. It is dense — long sentences with parentheticals and capitalized emphasis — but little is genuinely removable given the two-mode semantics being described.

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 destructive, side-effect-heavy mutation tool with no output schema, the description covers prerequisites, the two exclusive modes, side effects on saved routines, meal re-inference, and auth requirements. Nothing an agent needs to call it correctly appears to be 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 only 25%, so the description carries the burden, and it does: it explains the mutual exclusivity of `ingredients` vs top-level numerics, that values are absolute rather than deltas, that ingredient names/amounts are preserved under rescaling, and that logged_time is time-of-day only. It doesn't cover the individual nutrient fields or their bounds, though the schema supplies those directly.

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 opens with a specific verb and resource ("Correct an existing FOOD log") and immediately enumerates the editable facets (title, nutrition numbers, ingredient list, meal, time-of-day). It also scopes the tool to FOOD items, which separates it from the sibling log_exercise/log_water/log_weight 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?

It gives an explicit prerequisite ("Read get_today/get_day first"), names the exact source of the id (`recent`, type "food"), and lays out the decision rule between the two modes: send `ingredients` when composition changed, top-level numbers when only totals changed. It also states the constraint "edit one log at a time" and the token requirement.

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