AimYear

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

Annotations already declare the mutation profile (readOnly=false, idempotent=true, destructive=false), so the safety burden is partly lifted. The description adds useful context about what the token powers (stand-up/break reminders), but omits important behavior: whether re-registering overwrites an existing token for the same platform, and any auth requirements.

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, and the core action and its payoff are front-loaded before the usage note. 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 an input-only tool, existing annotations covering the mutation profile, and no output schema, the description is nearly sufficient. However, with 0% schema coverage it should explain the label parameter and idempotent/overwrite behavior for a repeated platform token.

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 all three parameters. The description mentions a 'device token' and 'manual token,' loosely mapping to the token parameter, but says nothing about the label parameter or the platform enum values (ios/android/macos/web), leaving the schema to carry semantics it does not actually document.

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 ('Register a device token') plus the concrete downstream effect (server reminders reaching the device). It contrasts with the automatic registration path ('the phone app registers itself'), though it never names sibling tools like list_devices or delete_device, so sibling disambiguation is only partial.

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 gives the use case: 'use this for testing or a manual token,' which implies the normal flow is automatic registration and this is the exception. No named alternative tool and no stated prerequisites, but the when-to-use condition is clear.

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, non-idempotent, non-destructive mutation, so the safety profile is covered. The description usefully adds a non-obvious side effect ("May classify a session that was unclassified"), which is real value beyond the annotations, but omits error/failure behavior when no running session exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short clauses with no filler, and the primary action plus target are front-loaded. The parenthetical is slightly awkward but still earns its place by disambiguating the session target.

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 2-parameter tool with no output schema, the description covers target and side effect but leaves a meaningful operational gap: behavior when no session is running, and any note-length/format constraints. Adequate but not complete.

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

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

Schema description coverage is 0%, so the schema documents nothing. The description compensates for session_id by explaining the default target, but adds nothing about the required 'note' parameter beyond "one-line," leaving its format/length constraints 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 ("Add a one-line note") and scopes the target ("a running session (this connection's, or session_id)"). It is distinguishable from siblings like add_session or record_progress, though it does not name any 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?

The parenthetical establishes which session is targeted by default, which implies usage. But there is no when-to-use vs alternatives guidance and no statement of what happens if no session is running — the description leaves the caller to infer that requirement.

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 a non-idempotent, non-destructive write with openWorldHint=false, so the safety profile is covered. The description usefully reveals the two input modes (minutes ending now/at end, or start+end), but does not discuss permissions, overwrite behavior, or how duplicates are 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?

Two tight sentences with the core mode distinction front-loaded and no filler. Dense but readable, though the trailing activity list is somewhat elided and 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?

For a 12-parameter mutation tool with no output schema, the description covers the central time-entry semantics but omits the meaning of many supporting parameters. It is adequate for the common case but incomplete against the schema's complexity.

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 67%, and the description adds real meaning for the time parameters (minutes vs start+end HH:MM on a date). It says nothing about area, weight, exclusive, itemId, stepId, leverId, projectId, or the required 'task', leaving several parameters undocumented in both places.

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 ('Add past time') and constrains scope to untimed past time, which implicitly separates it from start_session/stop_session. It is clearly about logging a session, though it does not explicitly name the timed siblings it competes 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 condition 'past time that was not timed' gives implied guidance on when to use this versus live timers, and the activity list (calls, children, workout, paid work, away work) frames typical use. However, no alternative sibling is named and no when-not guidance is 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 cover the mutation profile (not read-only, not idempotent, non-destructive), so the description's job is to add more, and it does: input validation that rejects abstract steps and a warning behavior for non-blocking preparation. It stops short of saying whether steps are appended to or replace existing ones, or what a rejection response looks like.

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 the quoted example earns its space by making 'concrete' operational. The closing 'hard-lever' sentence is terse to the point of being cryptic without prior context.

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 a nested step array, zero schema coverage, and no output schema, the description covers content quality well but leaves the parameter contract and the return/failure behavior unexplained. An agent knows what a good step looks like but not how to populate the fields or interpret the result.

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 milestoneId, the step object shape, or why leverId and estimateMin exist. The 'few work blocks' phrasing hints at estimate sizing and 'hard-lever' hints at leverId, but both are too oblique to guide an agent filling in those fields.

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 ('Add concrete steps to a milestone') and immediately disambiguates what a step is versus an abstract task, which separates it from edit_step/delete_step conceptually. It doesn't explicitly name sibling tools like set_milestones or next_steps, so the differentiation is implied 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?

Gives concrete inclusion criteria ('fits a few work blocks'), an explicit exclusion ('abstract steps are rejected'), plus ordering guidance (hard-lever first, prep only where it blocks). It does not say when to use this versus next_steps or set_plan, so the alternative-routing is absent.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value beyond them by disclosing the interaction contract (problems[] / next_question) and that the caller should iterate until problems is empty. It does not describe return shape in detail, but the annotations carry most of the behavioral burden.

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 paragraph with zero filler: purpose, rubric criteria, side-effect guarantee, and the follow-up loop are all front-loaded. Every clause earns its place and nothing is repeated from structured fields unnecessarily.

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?

Even without an output schema, the description names the returned fields and the loop-termination condition, and it explains that nothing is mutated. For a 5-param, 0-required validation tool this is sufficient for an agent to call it and act on the result 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 60%, and the description compensates by enumerating the rubric semantics each field must satisfy (countable metric, value today for baseline, target, deadline within 12 months), which maps to metric/baseline/target/deadline and adds meaning beyond the raw schema types. The 'title' parameter is not addressed, leaving a minor 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 verb (check) applied to a specific resource (a goal that is not saved yet) against an explicit rubric. It clearly distinguishes this tool from set_goal by noting the goal is unsaved and that nothing is persisted, so an agent knows exactly what this does before opening the 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?

Gives explicit workflow guidance: loop until problems is empty, then call set_goal. The alternative (set_goal) and the condition that selects it are both named, so the when-to-use/when-to-proceed logic is fully specified rather than 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — reminders stop — but says nothing about auth requirements or whether removal is reversible. With annotations carrying the core disclosure, a 3 fits.

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-loaded with the verb and resource, zero filler. It is efficient, though the very brevity is part of why parameter and usage detail are absent.

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 destructive delete whose annotations already cover safety, the description conveys the action and its effect, so an agent can proceed. The gap is the undocumented token parameter and absent guidance on alternatives; no output schema exists, so return values need not be explained.

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 'token' parameter has 0% schema description coverage, and the description never mentions how the device is identified or what form the token takes. For a 1-param tool where the schema does no explanatory work, the description should compensate but does not.

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 concrete verb and resource ('Remove a device') and adds the observable consequence ('stops receiving reminders'), which distinguishes it from add_device, list_devices, and the delete_session/delete_step siblings. It does not explicitly name a sibling, but the resource is unambiguous.

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

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

No when-to-use, when-not-to-use, or alternatives are given. Nothing tells the agent that list_devices or add_device are complements, or under what conditions deleting (vs. disabling) a device is appropriate.

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 destructiveHint=true, readOnlyHint=false, and non-idempotency, so the safety profile is covered. The description adds genuine value with 'A routine item is skipped for that day only,' clarifying that a routine occurrence is a temporary exception rather than a permanent deletion. It does not say whether non-routine items are removed permanently or whether the change 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?

Two short sentences, front-loaded with the core action, and the second sentence carries non-redundant scope information about routine items. Nothing is wasted.

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, non-idempotent mutation with no output schema, the description is thin: it does not state what the response is, whether removal is permanent, or how to re-add the item. Annotations cover the safety signal, but the agent lacks enough context on the non-routine deletion path.

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 only 50%: 'date' is documented with its format and timezone in the schema, but 'itemId' is undocumented in both schema and description. The description alludes to 'one item' and 'a day's plan' but adds no syntax, sourcing, or meaning beyond that, leaving the required parameter's semantics 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 ('Remove') and resource ('one item from a day's plan'), which is clear and scoped. It does not explicitly distinguish itself from the close sibling edit_plan_item or set_plan, so an agent must infer the boundary from names alone.

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

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

No when-to-use guidance, no prerequisites, and no named alternative (e.g., edit_plan_item for modifying rather than removing, or set_plan for bulk changes). The only guidance is the indirect semantics of skipping a routine, which is behavioral rather than usage-oriented.

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 destructiveHint=true, idempotentHint=false, and closed-world scope. The description adds value beyond that by disclosing that both running and finished sessions can be deleted, the semantic effect ('no longer counts'), and the default target when no id is supplied.

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, front-loaded with the core action and effect, then the parameter default. No filler or repetition.

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 destructive tool with no output schema, the description covers target selection, allowed session states, and effect, while annotations cover safety. It leaves unstated whether the deletion is recoverable and what happens to a session's associated steps/notes, which is a modest gap for a destructive 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 0% and the single parameter is undocumented in the schema, so the description must carry the load. It does so well for the optionality: omitting session_id deletes this connection's running session, which is the critical semantic. It does not say what form a valid session_id takes, but the default-behavior disclosure is the more important missing piece and it is covered.

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 ('Delete a session') and adds scope: 'running or finished, so it no longer counts,' which clarifies the effect versus merely stopping a session. It does not explicitly name the sibling it competes with (stop_session), so sibling differentiation is only 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?

The description explains the fallback behavior when session_id is omitted, which is a form of usage guidance, but it never states when to prefer delete_session over stop_session or edit_session. Usage is implied rather than directed, with no exclusions or alternatives named.

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 destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds nothing beyond that — it does not say whether the delete is permanent, whether the path is renumbered, or what happens to dependent steps. Not contradictory, but no incremental value.

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 wasted words, but its brevity comes at the cost of under-specification rather than genuine economy.

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 mutation with no output schema and undocumented parameters, the description omits reversibility, side effects on the surrounding path, and error behavior. It is too thin to fully equip an agent to invoke 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?

With one required parameter at 0% schema description coverage, the description carries the burden; it only implies the single-step target ('one step') without explaining what stepId is, its format, or where to obtain it.

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 (delete) and resource (step) with scope ('one step from the path'), which clearly separates it from delete_device, delete_plan_item, and delete_session. It does not explicitly name an alternative or contrast with sibling tools like edit_step, 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?

There is no guidance on when to delete a step versus editing it (edit_step) or restructuring via add_steps/split_attention. No prerequisites, permissions, or ordering caveats are 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 safety (readOnly=false, idempotent=true, destructive=false), and the description adds substantive consequences beyond them: status=retired drops it without finishing, done/retired advances the path to the next milestone, and 'Its steps are kept' clarifies no cascade deletion. This is exactly the kind of side-effect disclosure annotations cannot express.

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 terse sentences, front-loaded with the action and field list before the status semantics. No padding; every clause 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?

For a mutation tool with annotations covering the safety profile and no output schema, the description is nearly sufficient: it names the editable fields and the key status side-effects. Minor gaps remain around the meaning of non-status fields, but nothing critical to correct invocation is missing.

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

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

Schema description coverage is only 17% (only 'due' documents its YYYY-MM-DD format), so the description must compensate. It enumerates the mutable fields and partially explains 'status' via do/retire/done effects, but adds no meaning for 'metric', 'target', or the trivial 'milestoneId', leaving several parameters under-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?

States a specific verb+resource ('Change one milestone') and enumerates the exact editable fields (title, metric, target, due date, status), so the agent knows precisely what this tool mutates. It does not explicitly distinguish itself from the batch sibling set_milestones or edit_step, 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?

Usage is implied ('Change one milestone' contrasts implicitly with the batch set_milestones), but there is no explicit when-to-use guidance, prerequisites, or named alternative. The status semantics hint at intent but do not tell the agent when to pick this tool over 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 this a non-destructive, idempotent write. The description adds something annotations cannot express: that setting done=true cascades and also completes the linked path step. It still doesn't say whether 'change links' adds, replaces, or removes links, which is the one behavioral gap that matters for a mutation.

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 sentence, front-loaded with the verb and resource, with the mutable facets listed in a tight parallel enumeration and the higher-risk cascade note placed last. No filler whatsoever.

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 10-parameter mutation tool with no output schema, the description covers the intent of the common edits and one important cascade. It doesn't cover whether unspecified fields are left untouched, how link identifiers relate to one another, or what the itemId refers to, so an agent still has to guess at the mechanics.

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 10% across 10 params, so the description must compensate. It does map plain language onto roughly half of them (done, title via 'rename', estimateMin via 'estimate', area, isMainStep via 'main step'), but itemId, stepId, leverId, projectId and the partial-update semantics are unaddressed 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 ('Change one plan item') plus resource and then enumerates the exact editable facets: done state, title, estimate, area, links, main-step flag. It distinguishes itself from siblings only implicitly, though — edit_step and edit_milestone exist and nothing here says how a plan item differs from those.

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

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

No when-to-use guidance, no prerequisites, and no routing to alternatives such as edit_step, edit_milestone, delete_plan_item, or set_plan. The only conditional statement ('done=true also completes its linked path step') describes a side effect, not usage 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 a non-destructive, idempotent mutation, so the bar is lower. The description adds real behavioral context beyond them: the session 'is classified again after a change' (a side effect on derived classification) and the end-before-start rule implying an overnight span. It does not mention permissions or how partial updates behave.

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 verb and resource, then the field list, then the usage note. The long field enumeration is dense but earns its place across 15 parameters, 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 15-parameter mutation with no output schema, the description covers what can be changed, when to reach for it, and the reclassification side effect. A reader still has to consult the schema for enum values, defaults and id/format details, which is acceptable but leaves minor 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 coverage is 60%, so the description carries part of the burden. It groups the mutable fields into one readable list and adds genuine semantics the schema lacks: the midnight-crossing rule for a start/end whose end precedes the start. Otherwise the field enumeration largely mirrors schema property names.

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 (fix/edit) and resource (session) and enumerates exactly what is editable: start, end, task, area, project, lever, step, plan item, summary, outcome, attention share, weight. It also scopes the target as 'running or finished', which cleanly separates it from add_session, delete_session, start_session and stop_session.

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 explicit triggering conditions: 'Use it when a timer was forgotten or a session was labelled wrong.' That is a clear when-to-use signal. It stops short of naming alternatives (e.g. split_attention for dividing attention, stop_timer for live timers) or stating when-not to use it, so no 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?

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the scope is a single step, but it does not disclose partial-vs-full update semantics (whether omitted fields are preserved), permission requirements, or what happens to the other steps' ordering when 'order' changes.

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 sentence, front-loaded with the verb and scope, followed by the field list. No filler, no redundancy.

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 6-parameter mutation tool with no output schema, the description covers the field names but leaves out the required stepId, partial-update behavior, and any return/confirmation information. It is minimally viable rather than complete.

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

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

With 0% schema description coverage, the description must carry the parameter burden, and it does name most editable fields (title, status, order, lever, estimate). However, it omits the required stepId identifier, does not clarify units for estimateMin (minutes?), does not explain 'lever' vs the schema's leverId, or the meaning/range of 'order', so the compensation is only 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 gives a specific verb (Change) plus resource (one step) and enumerates the mutable fields, so it is clearly distinguishable from edit_milestone, edit_plan_item, and edit_session by resource. It stops short of naming those siblings or the delete_step alternative explicitly, so it is clear but not maximally differentiating.

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 use this tool versus delete_step, add_steps, or the other edit_* tools, and no prerequisites (e.g., the step must already exist). The only implied guidance is that this modifies an existing step, which the agent must infer.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description adds the concrete detection threshold (20+ minutes) and the anchoring boundaries (between first and last session of the day), which is genuinely useful behavioral context, but it says nothing about the shape of the returned data.

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 definition of a gap. Tight and waste-free, though the second sentence is a behavioral instruction rather than descriptive content.

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, read-only query with full schema coverage and no output schema, the definition supplies the key semantics (what counts as a gap). It could go slightly further on what the call returns, but the essentials an agent needs are 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?

Schema coverage is 100% and the 'date' parameter is fully documented in the schema ('YYYY-MM-DD in the user's timezone'). The description's 'of a day' only loosely corroborates that the date scopes to a single day, adding little beyond the schema baseline 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?

Names a specific resource ('gaps') and defines it precisely as 'untimed stretches of 20+ minutes between the first and last session of a day'. No sibling tool competes with this concept, so the agent can identify it readily, though it is phrased as a noun fragment rather than a verb+resource statement.

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 trailing 'Ask the user what happened there' implies a follow-up workflow, giving some sense of intended use. However, it never says when to call this tool versus alternatives (e.g. summarize_day), nor any prerequisite or exclusion; 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?

Annotations already establish this is a safe, read-only, idempotent operation, so the safety profile is covered. The description adds the useful defaults and the taxonomy of leak types it surfaces, but says nothing about the output shape or how the analysis is computed beyond the category list.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single front-loaded sentence plus a short default-range clause with no filler. The enumeration of categories is dense but every item earns its place as a definition of what a 'leak' is.

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 analysis tool with no required params and annotations covering safety, the description is largely sufficient — it defines the leak taxonomy (effectively the return content) and the default range. It lacks sibling-based routing guidance (find_gaps vs find_leaks), which is the main remaining gap.

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

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

Schema coverage is 100%, so the format of from/to is documented. The description adds the default window ('Default the last 7 days'), which the schema does not convey, giving it slightly more value than the baseline 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 recognizable purpose — identifying where time leaks — and enumerates the specific leak categories (goal work while the main step waited, overrides, unplanned work, switching, missed main steps, etc.), which is specific and distinctive. It does not, however, differentiate itself from the sibling tool find_gaps, which seems closely related given 'gaps' is listed as one leak category.

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 guidance offered is 'Default the last 7 days,' which addresses the time window but says nothing about when to choose this tool over alternatives like find_gaps or summarize_day. There are no when-to-use or when-not conditions.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety and determinism profile is fully covered by structured data. The description adds only that the result is a computed budget breakdown with explicit 'unaccounted for' accounting, plus the ambiguous 'Nothing is assumed' remark, which is too vague to count as real behavioral disclosure.

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, front-loaded with the core concept (168-hour weekly budget) followed by the breakdown components. No wasted text, though the trailing 'Nothing is assumed' is an unclear fragment that slightly dilutes it.

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 describing the return value, and it does enumerate the main components (overhead, committed hours per area, focus windows, unaccounted time). It is adequate for a parameterless read tool, with only the vague final sentence leaving residual ambiguity.

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 clarify; the baseline for a parameterless tool is 4. The description correctly implies no input is required.

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 — a weekly 168-hour time budget — and enumerates what it contains (overhead, hours committed per area, focus windows, unaccounted time), which is more informative than the title alone. It does not, however, distinguish itself from close siblings like summarize_week, find_gaps, or get_planning_context, which an agent would need in order to choose correctly.

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 such as summarize_week or find_gaps, and no prerequisites or context triggers are given. The closing phrase 'Nothing is assumed' is cryptic and does not function as usable 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 carry readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about the nature of the returned data (recurring weekly time blocks), but says nothing about scope, filtering, or freshness since there is no output schema to lean 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?

A single front-loaded sentence covering the resource and its contents with no filler. It is efficient, though the elliptical noun-phrase style means no explicit verb is stated.

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

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

With no output schema and no annotations covering the data shape, the description must explain returns; it names the three categories but not their structure, ordering, or time horizon beyond 'weekly'. Adequate for a simple parameterless read, but thin for a tool whose output the agent must interpret.

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. The description correctly implies a parameterless full retrieval and introduces no misleading argument expectations.

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 precisely and enumerates the three categories it returns (commitments, overhead, focus windows) with concrete examples, so an agent knows what data comes back. It doesn't explicitly contrast with the sibling set_commitments, so it falls 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?

There is no guidance on when to call this versus alternatives such as get_routines, get_capacity, get_planning_context, or the writing counterpart set_commitments. The agent must infer usage entirely from the tool 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description's useful addition is that there is exactly one goal and a fixed set of fields, but it says nothing about failure behavior when no goal exists or how the 'levers' values are structured. With annotations carrying the burden, a 3 is appropriate.

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: the resource and its scope are front-loaded, and the ordering directive is appended where it is easy to scan. 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?

There is no output schema, so the description must convey what comes back, and it does so by listing the goal fields plus the hard/comfortable lever distinction. The parenthetical '(hard/comfortable)' and 'other projects' are slightly underspecified, keeping this from a 5.

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 sets a baseline of 4 per the rubric. The description does not need to explain any inputs, and the field list it provides is about the return payload rather than parameters, so it neither helps nor hurts here.

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 precisely ('The one yearly goal') and enumerates its contents (metric, starting value, current value, target, deadline, levers, projects), which is enough for an agent to distinguish it from set_goal or check_goal_draft. It never states the verb 'retrieve/get' explicitly, but the resource-level specificity still lands clearly above a generic 3.

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 first in most flows' is explicit, actionable ordering guidance that an agent can act on immediately. It does not name an alternative or a when-not-to-use condition, so it stops short of the 5 that would require routing between siblings like check_goal_draft or set_goal.

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, idempotentHint=true, destructiveHint=false and a closed world, so safety is covered. The description's real contribution is disclosing the shape of the payload (sessions with attention shares, timer, main step, minutes, streak, nudge), which matters because no output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no preamble and no waste; the most important element (what is happening now) is front-loaded before the colon, and the return fields follow 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?

With no output schema, the description is the sole source of return-value information, and it enumerates the payload fields adequately for a zero-argument read tool. It stops short of anything about freshness, ordering or how empty states appear.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The schema is empty and fully described, and there is no parameter syntax the description could usefully add.

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

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

The description concretely enumerates what the tool returns: running sessions with attention shares, the timer, today's main step, minutes, streak and a nudge. That content list makes it clearly distinct from summarize_day, get_plan or get_capacity, even though no sibling is named. The verb itself is only implied by the title 'Get now', 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?

There is no statement of when to call this versus alternatives such as summarize_day, get_planning_context or get_path, and no prerequisites or exclusions. The dashboard-like content implies a 'current status' use case, but the agent has to infer it entirely.

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 (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuine value beyond that by disclosing the return shape — milestones carry a pace classification with the literal enum values ahead/on_pace/behind, each with steps, plus a current_milestone_id marker. Since there is no output schema, this is the only place that information exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero filler, and the primary content (what is returned) is front-loaded before the secondary note about current_milestone_id.

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 getter with no output schema, the description covers the essential return content: milestones, their pace state, their steps, and which milestone is actionable. It stops short of describing the wider milestone fields (dates, ids, completion) or step structure, but 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, so there is nothing for the description to disambiguate; baseline 4 applies. No misleading parameter claims are made.

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 concrete resource and its contents: milestones with pace values (ahead/on_pace/behind) and their steps. It is clear what comes back, but it never differentiates from close siblings like get_plan, get_goal, get_now, or next_steps, so an agent still has to guess which of these to reach for.

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 tool should be preferred over get_plan or next_steps, and no prerequisites. The clause about current_milestone_id explains how to read the output rather than when to call the 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered externally. The description adds nothing beyond that – no note on what the returned plan contains, whether it mixes sessions/tasks/milestones, or how empty days behave.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single fragment with zero waste and the default is front-loaded, which is efficient. However, terse under-specification is not the same as good conciseness; the sentence omits the verb and any structure, leaning on the title to carry meaning.

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 retrieval tool with no output schema, the description should convey at least roughly what a 'plan' object is (items, sessions, goals) and whether an absent day returns empty or an error. None of that is present, leaving the agent able to call it but not to know what it will get back.

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 100% for the single date parameter, which already documents the YYYY-MM-DD format and user-timezone semantics. The description's '(default today)' adds the default behavior that the schema omits, but that is a marginal increment, 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?

The description is a noun phrase, 'The plan for a day (default today)', with no verb, but it does identify the resource (the day's plan) and a scope. It does nothing to distinguish itself from close siblings like get_planning_context, next_steps, get_commitments, or get_routines, so an agent must guess which retrieval tool it wants.

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 parenthetical '(default today)' hints that the date can be omitted, which is mild usage guidance. There is no statement of when to prefer this over the other plan/context/goal readers in the sibling list, and no 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 readOnly, idempotent, non-destructive, so safety is covered. The description adds useful behavior: it defaults to tomorrow and describes the aggregated content returned, which the annotations do not convey. No output schema exists, so this enumeration carries real weight.

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 compact sentences, front-loaded with the payload contents, then the default, then the workflow routing. Every sentence earns its place with no redundancy.

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-optional-param, read-only tool, the description lists the returned context and the default date, compensating for the absent output schema. Coverage is nearly complete, though it doesn't state the response format or the date-selection effect on the aggregate windows.

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 format (YYYY-MM-DD, user timezone) is already documented. The description adds the default behavior ('Defaults to tomorrow'), which is meaningful semantics not present in the schema, exceeding the baseline 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?

States a specific resource (a bundle of planning context) and enumerates its contents: goal and pace, next_steps, yesterday's summary and undone items, week balance, days since a hard lever. It also distinguishes its role from siblings by noting the agent plans and then calls set_plan rather than get_plan/next_steps.

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?

Clearly positions this as the first step of a planning workflow and names the follow-up tool (set_plan), which is strong context. It lacks explicit 'when not to use' exclusions (e.g., versus get_plan or next_steps), so it stops short of the top score.

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, idempotentHint, and non-destructive, so the safety profile is covered. The description adds genuinely useful domain context — routines are auto-added by the server to each matching weekday's plan and shared across devices/agents — but says nothing about what the read returns or its shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with definition before the behavior note, no filler. The quirkiness of the example is harmless but slightly informal for a tool description.

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 safety, the tool is simple enough that the description is nearly sufficient — but it never tells the agent what a call actually yields, which is the one thing a 'get' tool should clarify.

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?

Zero parameters, so per the calibration baseline this scores 4. There is nothing for the description to compensate for.

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 defines what a routine is and notes server-side effects, but never states the retrieval action — that the tool returns the routine list. The verb is only inferrable from the name, and the sibling set_routines is not mentioned, so an agent gets concept, not purpose.

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

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

No when-to-use guidance, no prerequisites, and no mention of when to prefer this over set_routines or how it relates to get_plan/get_now. Usage must be inferred entirely from the 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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description adds no behavioral context beyond the field listing — no return format, no mention of defaults for unset values, no units. With annotations carrying the load, this is thin but not contradictory.

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 short fragment with no filler, and the three setting categories are enumerated compactly. It is efficient, though the fragmentary phrasing means there is no lead sentence establishing the action.

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 is the only source of what comes back, and it does name three categories of returned data. However, 'timer settings' is left vague and there is no indication of format, units, or whether all settings or only user-modified ones are returned, leaving the agent guessing about the response shape.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is no parameter surface for the description to explain, and the empty schema is consistent with a no-argument getter.

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 name and title ('Get settings') carry the verb, but the description itself is a bare noun phrase listing setting categories rather than stating that it retrieves current values. It does add field-level detail (timezone, reminder destination, timer settings) that tells an agent what 'settings' means here, but it never differentiates itself from the sibling set_settings.

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 at all — no mention that this is the read counterpart to set_settings, no indication of when an agent should fetch settings versus using get_planning_context or get_now. The agent must infer usage purely from the tool 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, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is fully covered. The description adds only the semantic content of the result set (which devices, last-seen time), with nothing about ordering or result size. Marginal added value over structured fields.

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 short sentence with no padding, and the key content is front-loaded. It reads as a noun phrase rather than a complete definition sentence, which is a minor structural weakness but costs nothing in length.

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, non-destructive listing with full annotation coverage and no output schema, the description conveys what the agent will receive. The missing piece is usage context relative to its siblings, but nothing required to invoke it correctly is 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?

The tool takes zero parameters, so there are no parameter semantics to explain and the baseline is 4. Schema coverage is 100% on an empty object, leaving nothing for the description to compensate for.

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 sentence describes the tool's output scope (devices eligible for reminders, plus last-seen timestamps) but never states a verb, so the purpose is only implied by the name and title. It also does no work to distinguish this from add_device or delete_device beyond the obvious read/write split.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the sibling tools (add_device, delete_device, list_sessions) that an agent would need to choose correctly. The agent must infer usage entirely from the 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, idempotentHint, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds genuinely new context beyond them: the default range is the last 7 days and results carry ids, which an agent needs to reason about output and defaults.

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 sentence with the subject and default window front-loaded and qualifiers following. It wastes no words, though it could be marginally clearer about the optional filtering.

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 list tool with full annotations but no output schema, the definition is adequate but thin: it does not mention pagination, result caps, sort order, or the shape of returned session objects beyond "ids". The essentials for calling it are present, but not the full behavioral 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?

With 50% schema coverage, from/to carry their format in the schema and area exposes its enum there, so the description's contribution is mainly mapping "project" to projectId. The projectId parameter itself remains undocumented in both the schema and the description, leaving the coverage gap only partially compensated.

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 (sessions), the scoping (a date range with a 7-day default), and the returned identifier fields. It is clearly distinguishable from the mutation siblings add_session, edit_session, and delete_session, though it never states an explicit verb like "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?

It conveys the default window and the optional area/project filters, which implies a browsing use case. However, it offers no explicit when-to-use guidance versus alternatives such as summarize_day/summarize_week or find_gaps, and no 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 establish the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, closed-world openWorldHint=false), so the description's main value-add is behavioral: it discloses scope ('open', 'current milestone') and result ordering ('hard-lever steps first'). That is genuine context beyond the structured fields, though it still says nothing about return shape or emptiness 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 sentence, front-loaded with the resource and scope, with the ordering rule following immediately. No filler, though the colon-fragment phrasing is slightly dense for an unfamiliar domain.

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?

No output schema exists, yet the description does not characterize what a 'step' contains or how many are returned by default. Safety behavior is covered by annotations and ordering is stated, but the undocumented 'count' parameter leaves a real gap for a tool whose whole purpose is to return a limited list.

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 'count' parameter (1-20), and the description never mentions it – no meaning, no default, no note that it caps the number of returned steps. With low coverage the description is expected to compensate, and it does not.

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 resource and scope – 'open steps of the current milestone' – and a clear ordering rule ('hard-lever steps first'), which tells the agent exactly what it gets back. The verb is only implied and no sibling (e.g. get_plan, get_now, get_path) is named to differentiate it, 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 phrase 'candidates for today's main step' gestures at a use case, but there is no explicit guidance on when to choose this over get_plan, get_path, or get_now, and no when-not or prerequisite conditions. Selection must be inferred from sibling names 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?

Annotations already declare idempotentHint=true and the read/write profile, so the safety burden is light. The description adds real value beyond that by explaining the upsert semantics ('calling again for the same date corrects it') and hinting at output ('Says when the target is reached').

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 purpose, then example, correction rule, and output hint. Short and largely waste-free, though the three clauses could be tightened slightly.

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 two-parameter write tool, the description covers purpose, correction semantics, and return behavior, compensating for the absent output schema. Only minor gaps (units, relation to goal definition tools) remain.

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% (date is documented with format and timezone, value is bare). The example 'I now have 4 customers' clarifies what value means as an absolute current count, but the description does not resolve remaining ambiguity such as units or whether deltas are accepted.

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 (record the current value of the goal metric) and grounds it with a concrete example. It is clearly distinguishable from sibling tools like set_goal or get_goal, which handle the goal definition rather than progress values.

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 note 'One value per date: calling again for the same date corrects it' implies when to call and how to fix mistakes, but there is no explicit guidance on when to use this versus set_goal or how it relates to check_goal_draft. 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 destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: 'Replace' clarifies that the whole list is swapped, and 'Pass existing ids to keep them' tells the agent how to avoid losing existing entries during a destructive replace.

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 with no filler. The replace semantics lead, followed by the two rules an agent needs. Every sentence 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?

For a single complex nested-array parameter with no output schema, the description covers the destructive-replace behavior, id preservation, and the ambiguous days encoding. It stops short of explaining how the nested kinds (commitment/overhead/window) interact, but the schema carries those.

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 gives no top-level description for the commitments array and no description for days, so the description must compensate. It does: 'days are ISO weekdays 1=Mon..7=Sun' supplies the encoding that the schema omits, and it explains the days-vs-timesPerWeek tradeoff. It does not cover the many nested fields, but those are documented inside 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?

States a specific verb and resource: 'Replace the list of recurring weekly commitments.' An agent knows exactly what is being mutated. However, it never distinguishes itself from the closely related sibling set_routines, which an agent could easily confuse with weekly commitments.

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 in-parameter rule of thumb ('use timesPerWeek instead when there are no fixed days') and a preservation rule ('Pass existing ids to keep them'), which is useful. But there is no guidance on when to call this versus set_routines or get_commitments, 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 only declare write/idempotent/non-destructive. The description adds real behavioral context beyond them: 'off' means timer and reminders only, nothing stored, no plan required, and 'full' is the default. It does not clarify what happens to already-recorded data when switching to 'off', which is the one consequential ambiguity.

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 with no filler, and the two modes are presented in a clean parallel structure with the default flagged immediately. The compression makes it slightly terse to parse but nothing is wasted.

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 two-parameter toggle with no output schema, the description covers mode semantics and the safety story is carried by annotations. It still omits the date-default behavior and whether prior recorded data is affected by switching to 'off' — a meaningful gap for a mutation 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 coverage is 50% and the mode enum carries no inline description, so the description does the work by defining both values ('full' = everything recorded, default; 'off' = timer and reminders only). It compensates well for the enum but says nothing about omitting 'date', leaving that parameter's absence behavior 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 the resource ('Tracking for a day') and enumerates the two possible states, so an agent can tell this is the switch controlling whether a day's data is recorded, distinct from set_settings or set_routines. It is slightly noun-phrase-led rather than verb-led ('Set...'), but the intent is unambiguous.

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

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

It gives useful selection context by naming 'full' as the default and explaining what 'off' means, which implicitly tells the agent which value to pick. However, it never states when to call this tool versus siblings like set_settings, nor any prerequisites or exclusions.

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 flag destructiveHint=true and idempotentHint=true, so the description gets credit only for what it adds: rubric validation with a problems[] rejection payload, and the promise that levers and projects are preserved across replacement. That last detail is genuinely useful side-effect information not present in structured fields.

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?

Four short, front-loaded sentences with the mutation/replacement behavior stated first. The closing 'area is which of the five life areas' sentence is slightly circular but earns its place as the only parameter note.

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?

Covers the mutation semantics, failure mode, and preservation guarantees, which is solid for a 5-required-parameter write tool with no output schema. It is still thin on success behavior and on the relationship to the draft-checking sibling, so an agent lacks a full picture of the intended flow.

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 43% across 7 parameters, so the description carries a compensation burden it does not meet: it explains 'area' as one of five life areas (largely redundant with the enum and 'default money'), but says nothing about why, metric, target, baseline, or the deadline format. The remaining parameters are undocumented in both places.

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 ('Save the yearly goal, or replace it with the next one'), which distinguishes it from read-side siblings like get_goal and draft-validation via check_goal_draft. It stops short of naming those siblings explicitly, so an agent must infer the boundary from the 'yearly goal' scope.

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?

Implies usage through 'save ... or replace it with the next one' and discloses that the rubric is validated on save, but never says when to prefer check_goal_draft first or what preconditions exist. Adequate but leaves the workflow decision 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 destructiveHint=true and idempotentHint=true, and the description adds real value beyond them: it clarifies full-replacement semantics, a hard validation rule ('At least one must be kind=hard'), and the id-preservation trick ('Pass existing ids to keep them'), which is exactly the behavior an agent needs to avoid clobbering data. It still does not say what happens to sessions classified under removed levers.

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 compact sentences, front-loaded with the replace action, then the validation constraint, then field hints. Dense but each sentence carries information; 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 destructive, single-parameter replace tool with no output schema, the description covers semantics, validation, and the id-preservation pattern needed to avoid unintended destruction. Minor gaps remain (fate of sessions tied to removed levers, required 'name'), keeping it short of a 5.

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 it does: it explains id (pass to keep), kind (must include hard), and that keywords/repos are classification hints from session task text. It omits 'name' and 'examples', but those are self-evident from 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?

States a specific verb and resource ('Replace the list of levers') and even defines the domain term ('the recurring kinds of goal work'), which is not obvious from the name alone. It aligns with the set_* sibling family but does not name any sibling to differentiate itself 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 mention of alternatives like set_commitments, set_plan, or set_routines that also replace list-like state. The replacement semantics are implied by 'Replace the list' but an agent gets no routing help.

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 flag destructiveHint=true and idempotentHint=true, and the description adds the concrete consequence beyond them: omitting an existing id deletes that milestone's steps. This spells out exactly what gets destroyed, which is the highest-value context for 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?

Three sentences, front-loaded with the replacement action, then the destructive rule, then the alternative. No filler; every sentence carries a distinct instruction.

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 nested-array mutation with no output schema, the description covers replacement semantics, cardinality, deadline constraint and cascade deletion. Failure behavior and required permissions are unstated but minor given the annotations carry the safety profile.

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 must carry the semantics, and it does: cardinality (2–6), ordering, the requirement that due precede the goal deadline, and the meaning of id as the existing milestone identifier. It does not explain metric/target units or types, leaving a small 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 verb and resource ('Replace the list of 2–6 ordered milestones under the goal') and pins down the shape (metric, target, due before the goal deadline). It explicitly distinguishes itself from the sibling edit_milestone, so an agent can route 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?

Names the alternative edit_milestone with the condition that selects it ('To change one milestone'), and states the replace-the-whole-list intent plus the id-passing rule. Clear context, though it doesn't enumerate broader when-not conditions (e.g. vs set_goal).

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 destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds behavior the annotations do not: it emits a warning when no item is on a hard lever, and items that remain 'keep their done state.' That is genuine behavioral disclosure beyond structured fields.

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 ('Replace the plan for a day') followed by the key invariant and edge-case notes. Four short sentences, no filler. The 'Other items: paid work, family, workout, etc. with their area' clause is slightly telegraphic but earns its place by mapping examples to the area field.

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, idempotent mutation with no output schema, the description covers the critical domain invariant (single main step), warning behavior, and done-state retention, with safety carried by annotations. Gaps remain around how date defaults and the unused optional fields, but nothing essential to a correct call is missing.

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

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

Schema coverage is 50%, and the description compensates by explaining isMainStep (exactly one must be true), the provenance of stepId (from next_steps), the hard-lever linkage for leverId, and the intent of area (paid work, family, workout, etc.). It leaves projectId, estimateMin, and the date format undocumented, so it is helpful but not exhaustive.

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 with scope: 'Replace the plan for a day.' This implicitly separates it from item-level siblings like edit_plan_item and delete_plan_item (whole-plan replacement vs single-item edit). It does not name any sibling explicitly, so it falls short of full 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?

It gives content rules for a valid call (exactly one isMainStep=true, ideally linked via stepId from next_steps, on a hard lever) rather than guidance on when to call this versus edit_plan_item, delete_plan_item, or add_steps. Usage is implied by 'Replace the plan for a day' but no when-not conditions or alternatives are 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 flag destructiveHint=true and idempotentHint=true, and the description goes beyond them by spelling out exactly what destruction means: omitted projects are removed. It also implies idempotence (pass the whole list). It doesn't note side effects on existing sessions or auth requirements, but the destructive mechanics are well disclosed.

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 tightly packed sentences, purpose front-loaded, and each clause adds usable information (scope, replace semantics, id retention). 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 destructive, no-output-schema mutation tool with annotations already covering safety, the description supplies the essential replace/keep/remove semantics. Minor gaps remain around the unmentioned area and repos fields and downstream effects on existing sessions.

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% for a single, nested array-of-objects parameter. The description clarifies the id field ("pass existing ids to keep them") and name/hints for editing, but the area enum and repos field are documented nowhere. It partially compensates but leaves meaningful gaps.

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 ("Replace") and resource ("the list of other projects"), and defines that resource concretely (paid work, other products, life routines) with its effect (sessions count as other work or life, not goal work). It implicitly distinguishes this from goal work, though it does not name a specific sibling 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 gives clear operating instructions for the replace semantics: leave an item out to remove it, change name/hints to edit, pass existing ids to keep. That tells the agent how to invoke it correctly. It stops short of stating when to prefer this over alternatives like set_goal or set_levers.

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 destructiveHint=true and idempotentHint=true, so "Replace the list" adds little on safety. But the description adds real behavioral context beyond the annotations: routines materialize as plan items from today onward, and passing existing ids preserves them. It does not state what happens to routines omitted from the new list.

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-loads the core purpose in the first clause, then packs workflow, defaults, and id semantics into a few dense sentences. Every sentence carries information, though the flow jumps between workflow, defaults, and id handling without clear ordering.

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, idempotent replace of a nested list with no output schema, the description covers the key agent needs: side effects (plan items created), id preservation, days encoding and default, and related tools. Still gaps on what removal of existing routines means for already-generated plan items.

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 does well for the two non-obvious fields: "days are ISO weekdays 1=Mon..7=Sun, default every day" and "Pass existing ids to keep them." But area, title, leverId, projectId, and estimateMin are left to the schema, so compensation is only 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?

States a specific verb and resource ("Replace the list of routines") and immediately clarifies what a routine is ("small steps that repeat on fixed weekdays"). It also names the sibling tools that interact with the resulting items (edit_plan_item, delete_plan_item, set_plan), so an agent can place it among alternatives.

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?

Explains the downstream workflow clearly: tick with edit_plan_item, skip a day with delete_plan_item, and that set_plan preserves them. However it never states the prerequisite for calling this tool directly (e.g. when to use set_routines vs get_routines, or that it overwrites the whole list), leaving some 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 readOnly=false, idempotent=true, destructive=false and openWorld=false, so the mutation/safety profile is covered structurally. The description adds a useful semantic side effect (timezone sets where each day starts and ends) and the phrase 'change any of' hints at partial updates, but it never confirms that omitted fields are left unchanged.

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 list and essentially no filler. The middle clause 'stand-up interval workMin, breakMin, longBreakEvery, longBreakMin' reads as an unstructured run-on that slightly hurts scannability, but nothing is wasted.

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 7-parameter mutator with no output schema and zero schema descriptions, the description covers most settings at least nominally and benefits from solid annotations. It still leaves units, accepted standup values, and the partial-update contract unstated, so it is adequate but not complete.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does explain timezone's IANA format with an example and workplace's purpose (reminders). However, workMin/breakMin/longBreakEvery/longBreakMin are only name-dropped as an ambiguous run-on 'stand-up interval' group, with no units or range guidance beyond what the schema already constrains.

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 clear verb (Change) on a settings resource and enumerates exactly which settings are mutable, which lets an agent map the tool to its job. It doesn't differentiate from the sibling get_settings, so it is clear but not sibling-aware.

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

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

There is no when-to-use guidance, no mention that get_settings is the read counterpart, and no statement of prerequisites beyond the implicit 'change settings'. The field list describes what can be set, not when or why to call 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 readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is carried by structured data. The description adds the scope of effect ('at once', 'Applies to the whole session'), which is real value, but it says nothing about permissions, conflicts, or how omitted sessions are 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?

Two tight sentences plus an inline example; the core action is front-loaded and every element (set weights, whole-session scope, finished-session alternative) earns its place with no filler.

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

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

For a batch mutation with a nested-object parameter and 0% schema coverage, the description covers purpose, scope, and the sibling alternative, and annotations cover the safety profile (no output schema needed). The remaining gap is parameter meaning—keys, summation, and partial-update semantics—which leaves it adequate but under-specified.

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% on a required nested object, so the description bears compensating weight. The inline example {"abc": 0.7, "def": 0.3} does show the key→number shape, but the description never states that keys are session identifiers, whether weights must sum to 1, or how excluded sessions behave.

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 gives a specific verb and resource ('Set attention weights of the running sessions') plus a concrete data example, and it explicitly names a sibling case ('For a finished session use edit_session'). The concept 'attention weights' is domain jargon left unexplained, and it does not distinguish itself from other set_* tools, so it falls just 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?

It states the operative condition ('running sessions') and gives an explicit alternative for the finished-session case ('use edit_session'). It does not cover the broader when/when-not against other state-setting siblings, so it is clear context without full 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?

Annotations only confirm it is a non-read-only, non-destructive write; the description adds substantial unique behavior: the ok|stop|plan_first verdict, the guard that no session is created on 'stop', the override escape hatch, and that multiple concurrent sessions share attention by weight. This is rich context beyond the structured fields.

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-loads the action and the timer nuance, then layers in the verdict, the stop guard, and concurrency. Dense but every clause carries information; no wasted 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 12-param, mutation tool with no output schema, the description covers the highest-value unknowns: the return verdict values, the stop/override workflow, and concurrency semantics. Remaining params are handled by the schema, so it is nearly complete.

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

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

Schema description coverage is 75%, so the schema already documents area, weight, direction, minutes, and override. The description mostly reinforces these (share attention by weight, override=true) rather than adding new parameter meaning, matching the baseline 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?

States a specific verb+resource ('Start a session of work and, if none is running, the timer') with an unusual dual effect. It doesn't explicitly differentiate from close siblings like add_session or split_attention, which could be confused with starting a session.

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 strong conditional guidance for the 'stop' verdict (relay the message, ask the user, retry with override=true), but says nothing about when to choose this over add_session or split_attention. Usage is implied rather than contrasted with 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 only declare non-readonly, non-destructive, non-idempotent; the description adds real behavioral context beyond that: the timer keeps running for other sessions, outcome=done completes the linked plan item or path step (a write side effect despite destructiveHint=false), and an ended session is refused. That is exactly the kind of side-effect disclosure an agent needs before invoking.

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, zero filler, and the core action plus target is front-loaded before the side-effect and refusal details. Every sentence carries distinct 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 mutation tool with no output schema, the description covers the important behavior: target resolution, plan-item/path-step side effect, timer semantics for other sessions, and refusal behavior. It stops short of describing the other outcome values or the attention_share correction, which is the only meaningful gap.

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

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

Schema coverage is only 25%, so the description has to carry weight. It explains the meaning of outcome=done and clarifies that session_id is optional and defaults to this connection's session, but says nothing about partial/abandoned or about attention_share (which only has a terse schema description). Two of four parameters remain under-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?

States a specific verb and resource ('Stop a running session') plus the target resolution ('this connection's, or session_id'), which lets an agent separate it from start_session, stop_timer, and delete_session. It also names the sibling it is not for one case (edit_session), so it is distinguishable 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 gives the when-not case: a session that already ended is refused and edit_session should be used instead. It does not, however, contrast with stop_timer (stopping just the timer) or explain what to do when no session is running, so one boundary is left implicit.

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?

Goes well beyond the annotations by disclosing real side effects: there is no paused state, resuming creates a brand-new session, and all running sessions are closed by this call. That concretely explains the destructive/irreversible semantics the annotations only flag abstractly.

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 scope, then the state-model caveat, then the parameter/alternative guidance. No filler and nothing repeated from 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?

No output schema exists, yet the description states the return value (break length). Combined with the disclosed side effects, the alternative tool, and parameter persistence semantics, an agent has everything needed to invoke 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 coverage is only 50% (summary is undocumented in the schema), and the description compensates by explaining that summary and outcome are persisted onto the sessions being closed. It also confirms the enum's default of partial indirectly via the schema, adding genuine meaning for the undocumented parameter.

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 (stop the timer) plus its scope: it also stops 'every running session with it'. It explicitly names the sibling stop_session, 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?

Gives a clear routing rule: pass summary/outcome here to save them on the closed sessions, or call stop_session first instead. That names the alternative and the condition that selects it, though it does not spell out the general when-not-to-use case (e.g. behavior when no timer is running).

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, idempotent, non-destructive and closed-world, so safety is covered. The description goes beyond that by enumerating the returned payload (minutes per area, classification, lever, sessions, gaps, overlaps, overrides), which is valuable since no output schema exists. It does not mention cost, pagination, or behavior for days with no data.

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 compact enumeration; every token carries content. The colon-list style is dense but readable, with no filler or repetition.

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 describing the response and does so at a field-group level, which is enough for an agent to decide whether to call it. The only gap is the omitted-parameter default and empty-day 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 100% and the single 'date' parameter is fully documented there (YYYY-MM-DD, user timezone). The description adds nothing about the parameter, and since it is optional (0 required) it does not explain what happens when it is omitted (presumably today). 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?

Names a specific verb+resource ('summarize day') and enumerates exactly what the summary contains (wall/attention minutes per area, classification, lever, sessions, gaps, overlaps, overrides), so an agent knows this is a read of aggregated daily data. It does not explicitly distinguish itself from the sibling summarize_week, but the day/week scope split is 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?

There is no when-to-use guidance, no prerequisites, and no mention of the sibling summarize_week as an alternative for multi-day rollups. Usage is only weakly 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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds useful behavioral content by disclosing the returned dimensions, but says nothing about pagination, permissions, or formatting. Given annotation coverage, a 3 is appropriate.

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 with the range constraint front-loaded and zero filler. It is compact and information-dense, though the fragmentary style slightly reduces immediate parseability.

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 enumeration of returned metrics ('goal share, hard share, area balance, overrides, streak, milestone pace') usefully compensates by telling the agent what it will get back. Combined with the fully documented single parameter and complete annotations, it is nearly complete; it only lacks explicit routing versus summarize_day.

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 100%, so the single 'date' parameter is already documented ('any day of the week, default today'). The description reinforces the week range and partial-week behavior for the current week, but adds no syntax beyond the schema, 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?

The description is a noun-phrase content enumeration ('main-step days, goal share, hard share...') rather than a verb+resource statement; the action ('summarize') is carried only by the title/name. It is specific about what the week summary contains and implicitly contrasts with the day granularity via 'Monday to Sunday', but it never states the operation outright or names the summarize_day sibling.

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 exclusion conditions, and no reference to the obvious alternative summarize_day. The weekly framing ('Monday to Sunday') implies the context, but the agent must infer it.

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