Siltwell

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the safety profile is covered. The description adds domain semantics about the entity's state (planned, not yet sown), which is genuinely useful, but says nothing about permissions, whether repeated calls create duplicate plans, or what is returned.

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 tightly written sentences: the exclusion/alternative comes first, followed by the usage trigger and a concrete example. No filler and nothing buried.

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

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

Covers the essential create-vs-plan distinction for an 8-parameter tool, but with no output schema the description should say what the call returns (e.g. a planned-planting identifier) and whether a duplicate submission is possible given idempotentHint=false. Those gaps are real, though not fatal.

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 bed, garden, method, cropSlug, targetDate and displayName. The description only illustrates bed and targetDate through the example ('Bed 2 on August 15') and never mentions quantity, notes or cropSlug, so it adds little beyond the structured 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 — 'Queue a future planting for a bed as part of a succession plan' — and explicitly contrasts the created entity with add_planting ('it is NOT yet sown'). An agent can distinguish it from add_planting and place_planting 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 an explicit when-to-use condition ('use when the user wants to plan ahead') and names the alternative tool plus the discriminating condition ('use add_planting for something the user already planted'). A concrete example utterance reinforces the trigger.

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=false, so the safety profile is known. The description earns credit by explaining the actual destructive action (a passed variety replaces the variety on an existing plant with the same name) and the catalog-creation side effect, which annotations do not convey.

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

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

Two sentences, zero filler, with the primary purpose front-loaded and the riskier replacement behavior stated second. 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 9-parameter mutation tool with no output schema, the description covers the core action and the destructive variety behavior adequately. It is thin on the timing/method parameters and silent on choosing between the many planting-related siblings, leaving meaningful gaps.

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

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

Schema coverage is 56%, so the schema documents some params. The description adds real meaning for 'variety' (replacement semantics) and implies 'bed'/'garden', but leaves method, dates (sownAt/transplantedAt), quantity, and notes to the schema, only partially compensating for the 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 ('record that the user planted/sowed something') and even describes the composite side effect of creating a catalog plant if new plus the planting in the named bed. It does not, however, distinguish itself from close siblings like add_planned_planting or place_planting, so an agent must infer which to pick.

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 and no alternative is named, despite several near-siblings (add_planned_planting, place_planting, update_planting). The agent gets no rule for choosing add_planting over a planned planting or a placement.

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 the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description only needs to add operational context. It restates that dimensions are optional and that type gates the bed kind, but says nothing about what happens on duplicate names, garden resolution failures, or permissions.

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 core action, followed by the enum semantics and optionality note. 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 create tool with no output schema, the description covers the action, the required discriminator's meaning, and optionality of dimensions, while annotations carry the safety profile and the schema documents the garden default. Nothing essential 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 coverage is 67%, with `name` and `type` undocumented in the schema. The description compensates by explaining the semantic meaning of the `type` enum (outdoor_bed = in-ground, etc.) and confirming the dimension fields are optional, which is genuinely additive detail beyond the raw enum list.

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 garden bed') and enumerates the valid bed types, making the created resource concrete. It does not explicitly contrast itself with siblings like update_bed or list_beds, so it stops short of full differentiation, 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?

Gives a clear triggering context: 'Use when the user wants a new bed or planting area.' There are no exclusions or named alternatives (e.g., when to prefer add_planting or place_planting instead), so it is clear context without 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?

Far exceeds the annotations: it details exactly what the archive destroys (removal from bed lists in app and tools, care schedules stop, queued plantings skipped), what survives (weather history keeps the name), irreversibility ('The app has no way to restore it'), and the blocking condition. The destructiveHint annotation only flags danger; the description explains its scope.

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?

Five short sentences, front-loaded with the core action, then consequences, then the blocking rule, then identification. No sentence is redundant, and the irreversibility warning is placed prominently.

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 covers everything an agent needs: side effects, irreversibility, failure precondition, and how to identify the target. Nothing material 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 100%, so both 'bed' and the optional 'garden' are already documented in the schema. 'Identify by bed name' reinforces the required parameter but adds no format or syntax detail beyond it, so the baseline of 3 is correct.

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 ('remove a bed from the garden') and immediately disambiguates the soft-delete semantics ('Siltwell archives it'), which reconciles the delete_bed name with the 'Archive a bed' title. An agent can distinguish this from update_bed or delete_planting without opening a 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 an explicit precondition and remedy: 'Blocked while the bed has active plantings; remove or finish those first.' That tells the agent when the call will fail and what to do instead. It stops short of naming the sibling tools (delete_planting, delete_planned_planting) that satisfy that precondition, so it is clear context rather than 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 already declare destructiveHint=true and idempotentHint=true, so the description's job is to add context; it does so by clarifying this is a hard, unrecoverable delete and by scoping it to unsown/queued entries. It adds no further operational detail (no permissions, no cascade behavior, no response shape), so 4 rather than 5.

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 tight clauses with zero waste: scope first, then the destructive/recoverability warning, then the alternative and the id source. Front-loaded and easy to scan.

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, non-idempotent-risk-free deletion tool whose annotations carry the safety profile and which has no output schema, the definition supplies everything needed: what it destroys, that it is irreversible, the fallback tool, and where to source the id.

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 both parameters (id, garden) are already documented, including the id's provenance. The description repeats the id source and says nothing about the optional garden parameter or its default beyond what the schema states. 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 (remove outright) and resource (an entry from the succession plan / queued future planting not yet sown), and explicitly contrasts itself with delete_planting. An agent can distinguish it from every other delete_* sibling without opening a 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 tool and the exact condition that selects it ('for a planting already sown/growing, use delete_planting instead'), and tells the agent where the id comes from (list_planned_plantings). No inference required.

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: it discloses that this is really an archive, that the planting vanishes from the app and from these tools, that care schedules stop, that harvests/events/photos are retained, and that there is no in-app restore path. Those are exactly the consequences an agent needs before committing to a destructiveHint=true operation, and none of them are recoverable from the schema or annotations.

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

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

Four tight sentences, front-loaded with the action and then the surprising archive semantics. Every clause carries information — scope, persistence, irreversibility, identification, trigger — 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 destructive, non-idempotent tool with no output schema, the description covers consequences and identification well. The remaining gap is failure/ambiguity handling — what happens when a plant name matches multiple plantings or nothing, given that no parameter is required.

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 baseline is 3. The description reinforces the lookup choice ('Identify by plant name or plantingId') but adds no syntax, precedence, or conflict-resolution rules for when both plant and plantingId are supplied, or for the zero-required-parameter case.

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

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

The first sentence gives a specific verb+resource ('Remove a planting') and the second immediately reframes it as an archive, which is more precise than the tool name suggests. It does not, however, distinguish this tool from the similarly-named sibling delete_planned_planting, which is a real ambiguity risk given the sibling list.

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

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

Explicit when-to-use guidance is present: 'Use when the user says to delete/remove a planting (e.g. one added by mistake).' It also states how to identify the target (plant name or plantingId). It stops short of naming alternatives or exclusions, so an agent facing 'delete my planned tomato' still has to guess between this and delete_planned_planting.

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=true and readOnlyHint=false, so the safety profile is covered. The description adds genuine context beyond them: that the operation deactivates reminders rather than purging history, and how the target is resolved. It omits confirmation/undo semantics, so not a 5.

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 effect and side effect, then the identification modes, then the trigger phrase. Dense and largely waste-free, though the em-dash clause about scope is slightly compressed and takes a re-read.

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

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

For a mutation tool with no output schema, the description covers targeting, effect, and usage trigger, and annotations supply the destructive/idempotent profile. Missing only secondary details like reversibility, confirmation behavior, or what happens to historical logs.

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 baseline is 3, but the description adds relational meaning the per-field schema text lacks: scheduleId is an alternative to the scope fields, garden-wide means passing neither plant nor bed, and type acts as an optional narrowing filter on any of those scopes.

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 ('turn off a recurring care schedule') and clarifies the real effect ('stops its reminders'), which is more informative than the title's 'Delete'. It doesn't explicitly name set_care_schedule as its counterpart, so sibling differentiation is only implied.

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

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

Gives a concrete trigger case ('Use when the user says to stop a watering/feeding reminder') and explains the two selection strategies (by scheduleId vs. by scope). It stops short of stating when not to use it or naming alternatives.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world reads, so the safety profile is covered. The description adds non-annotation context: the coordinate convention (origin at bed top-left), the three data categories returned, and the fact that placements are authored by place_planting. It does not mention error behavior for unknown beds or gardens.

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 payload, then the motivating use case. Every clause carries information — units, coordinate origin, and the unplaced-plantings case — with no repetition of the title.

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 characterize the return value, and it does so precisely: cm dimensions, xCm/yCm offsets from the top-left, wCm × hCm footprints, plus a distinct list of unplaced plantings. An agent has everything needed to issue the call and interpret the response.

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 both parameters ('bed' and 'garden', including the default-first-garden behavior) are already documented in the schema. The description adds no additional parameter-level meaning, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Read a bed's layout grid') and enumerates exactly what is returned: bed dimensions, each placed planting's footprint with coordinate origin, and unplaced active plantings. This clearly separates it from list_beds (enumeration) and query_plantings (filtered queries).

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

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

Gives a concrete usage scenario ('is there 60 cm free at the front of Bed 2?') that tells the agent what question this tool answers, and notes the counterpart tool that produces this data ('Positions are written by place_planting'). It lacks explicit when-not-to-use guidance or a named alternative for simpler bed metadata lookups.

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 the safety profile is handled. The description adds real behavioral context beyond that: the data source switches depending on whether a station is connected, falling back to a forecast. It still says nothing about freshness, units, or rate limits.

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: the first delivers the return payload, the second delivers the usage trigger. No filler and the content is front-loaded.

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

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

With no output schema, the description does the work of characterizing the return (weather plus per-bed soil readings), and a single optional parameter needs little explanation. Only finer details such as units or how beds without sensors appear are 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?

There is a single optional 'garden' parameter with 100% schema description coverage, including the default-to-first-garden behavior, so the schema carries the semantics. The description adds no additional parameter meaning. Baseline 3 applies when schema coverage is complete.

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

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

The description uses a specific verb+resource combination and enumerates the payload: current weather at a named garden plus per-bed soil moisture/temperature. It implicitly separates itself from get_forecast by including soil data and a station-vs-forecast fallback, but it never names that sibling to draw the boundary 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?

Concrete trigger phrases are given: 'how is the garden right now / should I water'. That tells an agent when this is the right call. No exclusions or alternative tools (get_forecast, get_soil_readings) are named, so the routing is clear but incomplete.

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 covered. The description usefully discloses that results include overnight-low frost alerts, but says nothing about return shape, units, or how far the frost alerts extend within the 7 days.

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

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

Two short sentences with zero filler, and the core output description is front-loaded before the use-case clause. Nothing here could be trimmed without losing 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 read-only, single-optional-param tool with no output schema, the description covers the horizon, the notable output feature, and the intended decisions it supports. Only minor gaps remain, such as units and whether frost alerts are per-night or summarized.

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?

Only one optional parameter, and the schema already documents it at 100% coverage ('Garden name; defaults to the user's first garden'). The description adds no format or naming detail beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource ('7-day forecast for the garden') and adds scope detail beyond the name by naming the frost-alert content. The 7-day horizon implicitly separates it from get_current_conditions, but no sibling is named, so differentiation is left to inference.

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

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

Lists three concrete use cases ('planting timing, frost protection, watering plans'), which is better than nothing, but gives no when-not guidance and does not address overlap with lookup_frost_risk or lookup_frost_dates, both of which also serve 'frost protection'.

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 the safety profile is fully covered without the description. The description adds only the result shape ('per-plant totals') and says nothing about ordering, date-window defaults, or result size limits.

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, purpose front-loaded before the usage cue, with no redundant or filler text. 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?

With no output schema, the description usefully signals the return shape ('per-plant totals') and the read-only list nature is carried by annotations. It is thin on the filter semantics and date-range behavior, but nothing essential for a 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?

The description never mentions any of the three filters, and the 'plant' parameter has no schema description at all (67% coverage). The 'per-plant totals' phrasing hints that plants are a dimension but does not tell the agent that 'plant' is a filter argument, so the description fails to compensate for the coverage 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 ('List harvests') plus a scope qualifier ('with per-plant totals'), which separates it from record_harvest and update_harvest by implication. It never names a sibling explicitly, so the differentiation 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?

'Use when the user asks what/how much they harvested' gives a concrete triggering condition rather than vague context. It stops short of naming alternatives (e.g. get_history or query_plantings) or stating when not to use it.

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 the safety profile is covered. With no output schema, the description usefully adds behavioral substance by disclosing what comes back (daily granularity, cumulative GDD at base 10 °C), which the annotations cannot convey. It omits any note on result size, date-range limits, or behavior when a garden has 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?

Two tight sentences: the first front-loads what data is returned, the second routes the agent to the right questions. No filler, no restatement of the title.

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, zero-required-param tool, the description plus a fully documented schema and rich annotations cover what an agent needs to invoke it. The lack of an output schema is partly compensated by the enumerated return metrics, though edge cases (empty history, long ranges) remain unaddressed.

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

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

Schema description coverage is 100% and both parameters ('since' with its 90-day default, 'garden' with its first-garden default) are fully documented in the schema. The description adds no syntax, format, or boundary detail beyond that, so the baseline of 3 applies.

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

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

The description gives a concrete verb+resource ('Daily weather history for the garden') and enumerates the returned metrics (min/max temp, rain, growing degree days with cumulative total), which clearly separates it from get_forecast and get_current_conditions by tense/scope. It stops short of naming those siblings explicitly, so it is clear but not fully differentiated.

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

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

It states when to reach for it: '"how warm/wet has it been" and growth-progress questions.' That is a clear usage context with a real user-intent cue. It offers no explicit exclusion or named alternative (e.g. 'for future weather use get_forecast'), so it falls short of a 5.

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 a closed world, so the safety profile is covered. The description adds genuinely new behavioral context: the results are computed/derived from the user's catalog and the garden's frost dates rather than stored records, and care tasks carry a rain-skip hint. It does not cover freshness/caching or any auth prerequisites, which keeps it from a 5.

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?

Content is front-loaded: the return contents come first, then the usage triggers. Dense but no filler sentences and no restating of the title. The comma-heavy first sentence is slightly overloaded but still readable.

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 carry the return-value burden, and it does enumerate all the payload parts (windows, zone, frost dates, care tasks). Given zero required parameters and a single optional one, an agent has enough to call it correctly; only ordering/shape details of the aggregated response are 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 schema has 100% description coverage for the single 'garden' parameter, including its default-to-first-garden behavior, so the schema carries the semantics. The description only obliquely references 'the garden's frost dates' and adds no format, naming convention, or error behavior beyond the schema. Baseline 3 is correct.

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 specific outputs (computed sowing/transplant windows, zone, frost dates, due care tasks) and their source (plant catalog + garden frost dates), so the agent knows exactly what comes back. It is clearly distinguishable from raw lookups like lookup_planting_windows or lookup_frost_dates because it presents derived/aggregated guidance. It stops short of naming any sibling explicitly, so it lands at 4 rather than 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?

Two concrete user-intent triggers are given in quotes ('what should I plant/start/transplant and when', 'what care is due'), which is strong when-to-use guidance. However, there is no when-not guidance and no alternative tool is named for the overlapping cases (get_season_plan, lookup_planting_windows), leaving routing ambiguous for an agent choosing between 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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description still adds real value beyond them: it stresses that the output is a proposal with no writes, and it discloses the return shape (every bed's chain, or one bed's chain plus remainingCount when the plan covers a single bed).

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 the proposal caveat and the return-shape note. It is dense and covers a lot of ground in three sentences with little waste, though the final return-shape clause is packed tightly.

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, so the description carries the burden of describing return values — and it does, covering both the multi-bed chain and the single-bed plus remainingCount case. Combined with the write-free guarantee, an agent has everything needed to call and interpret it.

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% and both parameters (today, garden) are fully documented in the schema, including their defaults. The description adds no format or semantics beyond that, so the baseline of 3 applies.

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

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

The description states a specific verb and resource — 'Compute the garden's rest-of-season planting schedule' — and immediately scopes it: every bed's next crops chained to first frost, deconflicted across beds with rotation and sow windows. That is far more specific than the name and clearly separates it from list/get siblings like get_plan or get_bed_layout.

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

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

It gives an explicit when-not ('Returns a PROPOSAL only — nothing is written') and names the follow-up alternative, 'use add_planned_planting to accept a row into the succession plan'. It stops short of contrasting against the near-name sibling get_plan, but the usage context is otherwise unambiguous.

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 safe, idempotent, non-destructive, closed-world read. The description adds freshness semantics ('latest') and the per-bed aggregation grain, which is genuinely useful. It does not discuss staleness window, units, or data-source cadence.

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

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

Two short sentences, zero filler, with the return payload front-loaded ahead of the usage hint. Nothing could be removed without losing information.

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

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

With no output schema, the description must convey the return shape, and it does so compactly (moisture %, temperature, bed names, one entry per bed). For a zero-required-parameter read tool with full annotation coverage, that is nearly sufficient; only units/freshness detail 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?

Schema coverage is 100% and the single optional 'garden' parameter is fully documented in the schema, including its default behavior. The description says nothing about the garden filter, so it adds no meaning beyond the schema — baseline 3 is appropriate.

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 ('get soil readings') and specifies exactly what comes back: latest soil moisture %, soil temperature, per bed, with bed names. This clearly separates it from weather-oriented siblings like get_current_conditions or get_forecast, 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 phrase 'Use for watering/sowing decisions' gives an intended-purpose cue, which is more than nothing, but it offers no when-not guidance and never names an alternative (e.g., get_current_conditions for ambient weather). Usage is implied rather than delimited.

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 only result-content detail (fields and the bed-type enum, plus cm units), not behavioral traits such as the default-garden fallback or ordering. Adequate but adds little beyond what annotations plus schema already imply.

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, no filler, and the payload of the tool (the fields returned) is front-loaded before the usage hint. Every clause earns its place.

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

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

With no output schema, the description usefully compensates by enumerating the returned fields and the bed-type enum, which is exactly what an agent needs to reason about results. The main remaining gap is the absence of any note about the default-garden behavior in the description body, though the schema covers it.

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

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

There is a single optional 'garden' parameter with 100% schema description coverage ('Garden name; defaults to the user's first garden.'), so the schema already carries the semantics. The description adds nothing about the parameter, which is the expected baseline when schema coverage is high.

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 ('List') and resource ('the garden's beds') and then enumerates exactly what is returned: name, type with enumerated values, dimensions in cm, notes, and active-planting counts. That is far more informative than the title alone, though it never explicitly distinguishes itself from the similar sibling get_bed_layout.

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

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

The sentence 'Use to see what beds exist and where there may be room' gives a clear motivating scenario, so usage is implied rather than absent. However, no alternative is named (e.g., get_bed_layout for spatial detail, create_bed for adding), so the agent gets no 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, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds real behavioral substance beyond that: the result set is restricted to status='planned' and done/skipped entries are excluded, which tells the agent what it will and won't receive. It stops short of describing ordering or volume, so not a 5.

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, each doing distinct work: definition and filter, usage triggers, and the sibling handoff. The scoping constraint is front-loaded 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?

No output schema exists, so the description ideally would say something about what a returned planting looks like, and it doesn't. Everything else an agent needs — scope, triggers, alternative, filter behavior — is present, and the tool is simple with one optional parameter.

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% and the single 'garden' parameter already documents that it defaults to the user's first garden. The description adds no parameter-level detail (e.g. what a garden name must match), so this correctly sits at the baseline where the schema carries the load.

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 (list) and resource (planned plantings) plus the exact filter scope: status='planned' only, with done/skipped omitted. It explicitly distinguishes itself from query_plantings, so an agent can separate 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?

Names three concrete user intents that select this tool ('what's coming up next', 'what they've planned to plant', 'review their succession plan') and gives an explicit alternative for the opposing case: 'For plantings already in the ground, use query_plantings instead.' Both when and when-not are 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 cover the safety profile (not read-only, non-destructive, non-idempotent), and the description adds the dismiss-vs-cured duality and the reminder concept. But it doesn't disclose what a dismissal does, whether the reminder is removed, or what permissions/state is required — meaningful gaps for a mutation tool with no output schema.

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

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

Two tight sentences, front-loaded with the core action and followed by usage triggers. Zero 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?

Adequate for a small 3-param mutation tool, but with no output schema and only 67% parameter coverage, the definition leaves the dismiss behavior and the relationship to sibling logging tools underspecified. Enough to call correctly, but not fully 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 coverage is 67%, which is moderate. The description implies the cured/dismissed distinction (kind) via its two stated use modes, but adds no detail on garden or plantingId semantics beyond what the schema already documents. Baseline for partial coverage with no extra description detail is 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 clear verb+resource: recording that a crop finished curing, with a parenthetical for the dismiss variant. It distinguishes the tool's purpose but does not differentiate it from siblings like record_harvest or log_event, which also record crop lifecycle events.

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

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

The second sentence gives explicit natural-language trigger phrases ('cured', 'dried', 'trimmed', 'stored') and example crops, which tells the agent when to invoke it from user speech. However, it does not explain when to prefer log_event or record_harvest, leaving ambiguity among closely related recording tools.

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

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

Annotations already declare this is a non-idempotent, non-destructive write, so the safety profile is covered. The description adds attachment behavior (where the record lands), but says nothing about retry duplication risk, whether logged events can later be edited, or permission requirements. Adequate given annotation coverage, not rich.

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

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

Two sentences, no filler, and the enumeration of event types is front-loaded before the attachment mechanics. Every clause carries information the agent needs either to select the tool or to populate 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?

For an 11-parameter write tool with no output schema, it covers purpose, required type, attachment targets, and precedence; remaining per-type parameters (amount, product, pestName, severity) are already documented in the schema. Only the absence of post-write behavior (duplicate risk, retrievability) is a small 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 description coverage is 82%, so the baseline is 3, but the description adds a precedence rule the schema does not state: if both plant and bed are given, the event attaches to the plant's planting. It also clarifies the plant target as the 'active planting', which sharpens ambiguity in a multi-planting model.

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 (record) and enumerates the resource domain precisely ('watered, fertilized, transplanted, pruned, pest sighting, treatment, frost damage, or a note'), which maps directly to the type enum. An agent can distinguish this from sibling writers like record_harvest or log_curing without opening a 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 clear routing guidance: attach to a plant's active planting via `plant`, to a bed via `bed`, or garden-wide with neither, plus the tie-break rule when both are supplied. It doesn't name an alternative sibling for overlapping cases (e.g. harvesting), but the scoping context is explicit.

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 read-only, idempotent, non-destructive profile, so the description's job is to add context — and it does: data provenance (10 years of weather records), an auth note (works without a Siltwell account), and output format (MM-DD). It does not discuss latency, rate limits, or fallback behavior when coordinates and place conflict, but the essentials are present.

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 tight sentences with no filler: the deliverable first, then the account/format constraints, then the sibling alternative. Every sentence earns its place and the most decision-relevant information is front-loaded.

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 name the return values, which it does completely (spring frost, fall frost, hardiness zone) and even specifies the date encoding. Auth requirements and the sibling boundary are also covered, leaving nothing an agent needs to call this correctly.

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

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

Schema description coverage is 100%, so the schema already documents place, latitude, and longitude with the 'give lat/long instead of place' rule. The description adds the MM-DD date format but no parameter-level guidance, so the baseline 3 is correct.

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 (lookup) and exactly what is returned: average last spring frost, average first fall frost, and hardiness zone. It explicitly distinguishes itself from the sibling get_plan by contrasting the generic place lookup with the signed-in user's microclimate-adjusted garden 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?

Names a concrete alternative (get_plan) and the condition that selects it (the signed-in user's own garden, where microclimate adjustment matters), plus that no account is required. It does not differentiate against the other frost/season-adjacent siblings (lookup_frost_risk, lookup_growing_season, lookup_planting_windows), which leaves some selection ambiguity.

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, openWorld), and the description adds genuine value beyond them: the date convention ('each frost night is dated by the morning its low falls on') and the auth fact that it works without an account. No contradictions.

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 tight sentences, front-loaded with the core capability, then the interpretation rule, then the sibling routing. 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?

There is no output schema, and the description partially compensates by explaining how frost nights are dated, which is the key interpretive detail. It could say more about the shape of the returned lows, but an agent has enough to call and use it correctly.

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

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

Schema description coverage is 100%, so the schema already documents place, latitude and longitude and the omit-place fallback. The description adds no syntax or format detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Forecast lows for the next 7 days ... and the nights at risk of frost') with a clear scope of 'any place'. It explicitly separates itself from the sibling get_forecast by noting that one applies the garden microclimate adjustment for the signed-in user.

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

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

Gives an explicit routing rule: use this for arbitrary places / no account, use get_forecast for the signed-in user's own garden. It does not address the closely related sibling lookup_frost_dates, so the alternative coverage is strong but not exhaustive.

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, openWorld). The description adds non-obvious context beyond annotations: it works without a Siltwell account, and it discloses what is returned (season length, seasonal GDD, crop heat suitability). It does not repeat the annotations.

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

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

Two sentences, zero waste, front-loaded with what the tool returns before the routing guidance. 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?

No output schema exists, but the description compensates by describing the return content (frost-free season length, seasonal GDD, crop ripening verdict). Auth context (works without an account) and sibling routing complete the picture, though pagination/units are not addressed.

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 all three parameters (place, latitude, longitude) are already documented in the schema, including the 'omit place to use your garden' behavior. The description confirms 'at any place' but adds no syntax or format detail beyond what the schema provides. Baseline 3 is appropriate.

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 (look up) and resource (frost-free season length and growing degree days) with concrete outputs including whether heat-loving crops ripen. Clearly distinguishes itself from siblings get_plan and get_history, which it names 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?

Explicitly routes the agent: use this for any place, or omit place for the signed-in user's garden; use get_plan for microclimate-adjusted frost dates and get_history for daily GDD. Names the alternatives and the conditions that select them.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuinely new behavioral context: no account is required, and omitting crops caps the result at the 30 earliest-next-step crops. It does not discuss result shape beyond the count, so it stops short of a 5.

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 sentences, none wasted, with purpose and scope front-loaded before the sibling comparison. The 'Dates are YYYY-MM-DD' aside is a small interruption but still earns its place as a format contract.

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 must carry return semantics, and it does explain the default result set (30 soonest crops), the crop-selection mode, and the place/lat-long resolution. It stops short of describing per-crop fields (next step, days left) in detail, but is sufficient to call the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents crops, place, latitude and longitude, including the 'omit to use garden' behavior. The description restates the crops default and adds only the date format convention, which is the expected baseline when structured fields do the heavy lifting.

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 (look up) and resource (planting windows: start indoors, plant out, fall sow) scoped 'at any place, crop by crop'. It names the sibling get_plan and the condition that separates them, so an agent can route between them 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 explicit when-to-use context ('works without a Siltwell account') and an explicit alternative with its own trigger ('for the signed-in user's own garden, get_plan ...'). It also describes the omitted-vs-supplied crops behavior, which tells the agent how to call it in two distinct modes.

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 real context by defining the coordinate frame ('measured from the bed's top-left corner') and the footprint semantics. It does not say what happens to a planting's prior position when it is moved or whether overlaps with neighbors are allowed, which keeps it out of the top band.

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 action and its effect, then parameters, then usage and the exclusion. No filler and nothing buried at the end that an agent needs first.

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 mutation tool with no output schema, the description covers purpose, units, coordinate origin, identifier options, usage context, and a fallback path. It omits any mention of the 'garden' parameter (the schema covers its default), which is a minor gap rather than a blocking one.

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 baseline is 3; the description earns an extra point by stating the either/or relationship between plant name and plantingId, which the schema presents as two independent optional properties with no indication they are alternatives. The coordinate-origin explanation is helpful but partly duplicates the schema's 'X offset from the bed's top-left'.

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 pair ('place or move') and resource ('a planting on its bed's layout grid'), plus the exact effect (sets position and footprint in cm). This is clearly distinguishable from siblings like add_planting, update_planting, and get_bed_layout 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 says when to use it ('when the user wants to arrange, position, or move a plant within its bed') and gives a when-not with an alternative ('a planting that already spans several grid squares, use the app's layout editor instead'). It stops short of routing between this and the sibling tools add_planting/update_planting, which is the remaining gap.

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, openWorldHint=false and destructiveHint=false, so the agent knows this is a safe, repeatable, local read. The description adds the breadth of returned data (what/where/when/how/status), but says nothing about pagination, result caps, or the fact that returned plantings may span multiple gardens.

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 that front-load the action and resource, then follow with concrete usage triggers. There is no filler and nothing that fails to earn 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 read-only, closed-world, annotation-covered list tool with a fully documented schema and no output schema, the description is nearly sufficient. It could go further by clarifying how it relates to list_planned_plantings and get_history, but nothing needed to call 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?

Schema description coverage is 100% with all three params documented, so the schema carries the load and baseline 3 applies. The parenthetical 'what, where, when, how, current status' loosely echoes the filters but adds no syntax, default, or matching semantics beyond what the schema already states.

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 ('List the user's plantings') and expands the scope with what/where/when/how/status. It is clear on its own, but it never distinguishes itself from the many sibling listing tools, notably list_planned_plantings (planned vs. actual) and get_history/get_plan.

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

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

The second sentence gives concrete triggering intents: what was planted, when something was sown/transplanted, what's growing in a bed. That is strong positive guidance, but there is no when-not or explicit pointer to alternative tools like list_planned_plantings or get_history.

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

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

Annotations already declare this is a non-destructive, non-idempotent write. The description adds genuinely useful behavioral context beyond them: lb/oz are normalized to grams on storage, and the active planting is resolved automatically. It omits return behavior and permission requirements, but the annotation baseline is already covered.

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 core action and immediately grounded in concrete examples. Every clause carries information; nothing is padding.

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 write tool with no output schema, the description covers the primary flow and unit handling but leaves the plant-vs-plantingId relationship, notes semantics, and the response shape unaddressed. The schema picks up garden and harvestedAt defaults, but the overall picture is only adequately 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 only 29% across 7 parameters, so the description must compensate. It clarifies the quantity/unit pair through examples, the lb/oz-to-grams conversion, and that the planting is resolved automatically (hinting plant/plantingId may be optional), but it says nothing about notes, garden, or harvestedAt.

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 pairs a specific verb (record) with a specific resource (harvest) and reinforces it with two concrete examples of the natural-language input it accepts. An agent can distinguish it from update_harvest or get_harvests, though the description never names those siblings 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?

It hints at one usage behavior ('resolves the plant's active planting automatically') but gives no when-to-use guidance relative to alternatives like update_harvest or log_event, and no exclusions. The agent must infer from the name alone which tool fits a given situation.

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 the full safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds no behavioral details beyond that, such as result ordering or pagination. With annotations carrying the load, this is adequate but not enriching.

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 zero filler, front-loading the resource and event scope before the usage cue.

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 filtered read tool with no output schema, the description covers purpose and usage. It could mention that results are event records or hint at default behavior, but nothing essential 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 80%, so the schema already documents limit, plant, since, and garden. The description's event list maps loosely to the type enum but adds no new parameter syntax or format details. Baseline 3 is appropriate.

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

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

The description states a specific verb (Search) and resource (the garden log) and enumerates the event categories it covers. It's clearly distinguished from siblings like get_history or query_plantings by focusing on logged events.

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 a clear usage context ('when the user asks when they last did something or what happened in the garden'), but does not name alternative tools or state exclusions, keeping it at 4 rather than 5.

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 declare the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), and the description adds genuine constraints on top: recurrence is either everyDays OR weekdays, and at most one of endsOn/endsAfter. It does not disclose duplicate-handling, permission requirements, or what happens to an existing schedule, so it stops short of full behavioral coverage.

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 compact sentences, front-loaded with the core action and scope, then the two constraint rules. Every sentence carries routing or constraint information; 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 an 11-parameter creation tool with no output schema, the description covers scope selection, recurrence mode, and termination conditions, which is the bulk of what an agent needs. Minor gaps remain around defaults resolution and behavior on conflicting existing schedules, though the schema covers defaults.

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 schema already documents every parameter, including the everyDays/weekdays and endsOn/endsAfter exclusivity rules. The description largely restates those same constraints rather than adding new semantics, so baseline 3 applies.

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

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

States a specific verb+resource ('Create a recurring care schedule'), enumerates the schedule types (water/fertilize/custom), and names the three scoping targets (plant, bed, whole garden). An agent can distinguish this from delete_schedule and the planting-management siblings without opening any schema.

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

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

Gives an explicit trigger condition ('Use when the user wants a repeating watering/feeding reminder'), which is the key routing signal versus one-off logging tools. It does not, however, name the sibling to use for the inverse operation (delete_schedule) or state what happens if a schedule already exists.

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 disclose the safety profile (destructiveHint=true, idempotentHint=false, openWorldHint=false). The description usefully adds that the bed is keyed by its current name, but it never says what 'destructive' means here — whether omitted fields are preserved (partial update) or cleared — which matters given idempotentHint=false.

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 tight sentences with the action and the lookup key front-loaded. The third sentence largely restates the field list from the first, which is mild redundancy rather than noise.

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 mutation with annotations covering safety and no output schema, the description covers identification and target fields acceptably. It omits the partial-update semantics and the garden-default interaction, which are the remaining gaps an agent would want before calling it.

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 57%, so several parameters carry no prose. The description confirms the addressable fields (name, type, dimensions) and reinforces that `bed` is the current name, but adds no meaning for widthCm/heightCm/lengthCm beyond their self-describing names. Baseline 3 fits.

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?

Specific verb+resource ('Change an existing bed') with the updatable fields named (name, type, dimensions), which cleanly separates it from create_bed, delete_bed, and list_beds. It does not explicitly name a sibling to disambiguate against, 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?

'Use when the user wants to rename a bed, change its type, or set/adjust its dimensions' gives concrete trigger conditions for invoking the tool. No exclusions or named alternatives are provided, so it is clear context rather than 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, destructiveHint=true, and idempotentHint=false, so the write/irreversibility profile is covered. The description adds meaningful context the annotations do not: the implicit target-resolution rule (most-recent harvest when only a plant name is given) and the exact set of mutable 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?

Two sentences, front-loaded with the action and target resolution, then the intent trigger. The em-dash clause carries real information rather than padding, though the first sentence packs several ideas in one breath.

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 needed and annotations carrying the safety profile, the description supplies what an agent needs: what is editable, how the target is resolved, and when to reach for it. Edge cases (multiple matching plants, no prior harvest, permission requirements) are left unstated.

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 86%, so most parameters are already documented — including the important lb/oz-stored-as-grams and garden-default notes. The description restates quantity, unit, notes, and date but adds no format or constraint detail beyond the schema, so the baseline applies.

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

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

States a precise verb and resource ("Correct a logged harvest") and defines the two targeting modes — latest harvest for a plant name, or a specific harvestId. It is clearly distinguishable from the sibling record_harvest by the correction framing, though it never names that sibling explicitly.

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

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

"Use when the user says a harvest they recorded was wrong" gives an explicit, actionable trigger condition that an agent can map to user intent. It stops short of naming alternatives (record_harvest for new entries, or deletion) or stating when this tool is the wrong choice.

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

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

Annotations already declare idempotentHint=true and destructiveHint=true, so the safety profile is partly carried. The description adds the status vocabulary and id sourcing, but given destructiveHint=true it never explains what an update overwrites or that re-status changes may be lossy. Useful but not rich on top of the annotations.

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

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

Two tight sentences: the capability list is front-loaded and the when-to-use triggers follow. No redundant padding, though the field list slightly duplicates the schema.

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

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

For a 6-param, no-output-schema mutation tool, it covers the id source, the primary status flows, and the reschedulable fields. Minor gaps remain around the garden default and the consequences of status changes, but nothing essential for invoking 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?

Schema coverage is 50%, so the description should compensate. It names status, targetDate, quantity and notes, but the status values it lists are already in the schema enum and targetDate format is already documented. It adds nothing for the undocumented 'garden' or 'notes' parameters, so it only partially fills the 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 ('Update a queued succession-plan entry') and enumerates the mutable fields (status, targetDate, quantity, notes). It implicitly separates itself from add_planned_planting/delete_planned_planting by framing this as modifying an existing id-sourced entry, though it never names those siblings 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?

Gives concrete when-to-use triggers: marking status 'done' when the user sows, 'skipped' when they decide to skip, or rescheduling/adjusting. It also tells the agent where the id comes from (list_planned_plantings). No explicit when-not or named alternative is given, keeping it short of a 5.

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 but give no detail. The description adds the crucial consequence: moving a bed clears any layout position, history stays attached, and you must re-place with place_planting. That's exactly the behavioral context annotations can't convey.

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

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

A single dense sentence, front-loaded with the status/field mutations and then the move behavior. It's information-rich and not padded, though the parenthetical is slightly long; still, every clause adds actionable detail.

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

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

For a 9-param mutation tool with no output schema and destructiveHint, it covers the critical side effects and identification paths. It could mention that 0 required params means at least one must be supplied, and doesn't state return shape, but the destructive move semantics are well covered.

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 compensates for the gaps: it maps status to its enum values, explains that bed takes the target bed's name, describes how to identify the planting (plant name or plantingId), and clarifies that variety is stored on the plant. It doesn't explain garden defaulting or the transplant date purpose beyond what the schema already says.

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 (update) and resource (planting), and enumerates exactly which fields can change. It distinguishes itself from sibling update tools and from place_planting by noting the move-to-bed behavior and the need to re-place layout after.

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 clear context for moving beds and explicitly names place_planting as the follow-up alternative for re-positioning. It doesn't cover when to choose update_planting over update_planned_planting, but the active/finished/failed status framing implies it's for existing real plantings.

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