Server Quality Checklist

Tool Scores

• start_zoneC
  2.4/5.0
  Behavior2/5

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

  With no annotations, the description must carry the behavioral burden. It mentions max 180 minutes, but doesn't disclose side effects (e.g., does it stop other zones? does it require a device? what happens on errors? whether it reports success?). The description is minimal and doesn't cover expected behavior beyond the basic action.

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

  Conciseness4/5

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

  The description is one concise sentence with no fluff. It states the action and a constraint (max 180 minutes). It is appropriately brief, though it could be more structured with parameter details. But as far as length goes, it's efficient.

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

  Completeness1/5

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

  With no annotations, no output schema, and only 2 required parameters, the description omits critical context: return values, side effects, prerequisites, what happens if another zone is running, and how the 'device' parameter is used. The description is far from complete for an agent to invoke it safely.

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

  Parameters1/5

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

  Schema coverage is 0% and the description doesn't explain any parameters. It mentions 'zone' and 'minutes' but doesn't add semantics like valid values, meaning of device, or how zone is identified. With 0% coverage, the description must provide this, and it doesn't.

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

  Purpose4/5

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

  The description states a clear verb ('Run') and resource ('a single zone') with a duration constraint (max 180 minutes). It differentiates from sibling 'start_zones' (plural) by specifying 'single zone'. However, it doesn't explicitly contrast with alternatives like 'run_schedule' or 'stop_watering', so it's not fully distinctive but clear enough.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool vs alternatives like start_zones, stop_watering, or run_schedule. It doesn't mention exclusions or prerequisites. The only usage hint is that it runs a single zone, which implicitly contrasts with start_zones, but no explicit decision guidance is given.

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

• set_rain_delayB
  3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It doesn't disclose side effects: whether it affects ongoing watering, whether it pauses schedules, or if it's persistent. It also doesn't state if the delay applies to all devices or just the specified device. This is a control tool with potential to disrupt watering, but these behaviors are undocumented.

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

  Conciseness5/5

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

  The description is one concise sentence that front-loads the key action and constraints. It covers the most important semantic details (0 clears, max 7) without wasted words. This is appropriately sized for a two-parameter tool.

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

  Completeness2/5

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

  Given the tool's complexity (control action, potential impact on watering) and no annotations, the description is insufficient. It lacks effects on current operations, device selection semantics, and return behavior. The absence of an output schema also means the description should hint at what the response indicates. With zero schema coverage, it's incomplete for safe, correct usage.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description only explains the 'days' parameter (0 clears, max 7). It does not explain the 'device' parameter at all—what it does, whether it's optional (schema shows default null but no description), or what happens when null. The description fails to compensate for the lack of schema docs on the second parameter.

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

  Purpose4/5

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

  The description clearly states the tool sets a rain delay in days, with specific semantics (0 clears, max 7). It clearly distinguishes from sibling tools like stop_watering and start_zone, as it's the only one dealing with rain delay. Slight vagueness: it doesn't explicitly say 'rain delay' is a watering-related setting, but it's clear enough.

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

  Usage Guidelines3/5

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

  The description implies when to use it (to set a rain delay), and the constraints (0 clears, max 7) provide usage boundaries. However, it doesn't explain when not to use it or mention alternatives (e.g., for immediate stop, use stop_watering). The context is clear but lacks explicit routing guidance.

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

• run_scheduleB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It says the tool 'starts' a schedule but does not explain side effects, prerequisites, whether an already-running schedule is replaced, or what the result of invocation is. This is a significant gap for an action tool.

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

  Conciseness4/5

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

  The description is a single front-loaded sentence with no filler, making it efficient and easy to parse. However, it is slightly under-specified relative to the number of parameters.

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

  Completeness2/5

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

  For a two-parameter action tool with no annotations and no output schema, the description is incomplete. An agent does not know the effect on the device, whether the operation has side effects, or what success or failure looks like.

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

  Parameters2/5

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

  The input schema has zero description coverage, so the tool description must compensate. It clarifies that 'schedule' accepts an id or name, but it entirely omits any explanation of the optional 'device' parameter, including its purpose or accepted values.

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

  Purpose5/5

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

  The description states a specific action ('Start') and resource ('stored schedule rule'), and clarifies the selector ('by its id or name'). This clearly differentiates it from sibling tools such as start_zone, start_zones, and list_schedules.

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

  Usage Guidelines3/5

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

  No explicit when-to-use or alternative guidance is provided. The phrasing implies the tool is for executing an existing schedule rule, but it does not state when to prefer this over start_zone or start_zones, nor any prerequisites.

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

• stop_wateringB
  3.3/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the full burden. It does disclose that the operation is immediate and affects both manual and scheduled watering. However, it does not clarify side effects such as whether schedules are permanently disabled, whether the device remains powered, or whether zones are returned to an idle state. This leaves ambiguity.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence that states the action, the scope, and the immediacy with no filler. It is easy to parse, though some parameter detail could be added without harming conciseness.

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

  Completeness3/5

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

  For a one-optional-parameter tool with no output schema and no annotations, the overall context is only partially complete. The core behavior is clear, but there is no mention of how the 'device' parameter should be used, what the result of the operation looks like, or what the expectations are. This is adequate but not fully helpful.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the single optional 'device' parameter is not explained in the description. The word 'controller' hints at what 'device' may refer to, but the agent is not told where to obtain a valid value, whether null is acceptable, or how the parameter influences the scope. The description fails to compensate for the schema's lack of parameter documentation.

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

  Purpose5/5

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

  The description names a specific verb ('Stop'), a specific resource ('all watering'), and a clear scope ('on a controller', 'manual or scheduled'). It immediately distinguishes this from sibling tools like start_zone, start_zones, and run_schedule, so an agent can identify the correct operation.

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

  Usage Guidelines2/5

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

  The description implies when to use it (when you want to stop any watering), but it gives no explicit guidance about when to choose this instead of related tools like set_device_power or set_rain_delay. No exclusions or prerequisites are mentioned.

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

• list_schedulesB
  3.4/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the full burden. The verb 'List' implies a read-only operation, but the description does not explicitly state that it has no side effects, nor does it mention any authorization or data-scope behavior. The 'stored' qualifier adds a hint that this returns persisted rules, not live state.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler. Every word adds meaning.

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

  Completeness3/5

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

  The tool is simple, with an output schema and one optional parameter, but the description leaves the 'device' parameter's role ambiguous and provides no context about when to use it. For a low-complexity tool, this is a minor gap, but the agent would have to infer parameter semantics from the schema title alone.

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

  Parameters2/5

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

  The only parameter, 'device,' has no description in the schema (coverage 0%). The description's phrase 'on a controller' gives a weak clue that 'device' refers to the controller, but it does not explain whether the parameter is a filter, how to specify it, or what omission means. With 0% schema coverage, the description should fully compensate, and it does not.

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

  Purpose5/5

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

  The description states a specific verb ('List') and resource ('stored schedule rules (watering times)') plus a location ('on a controller'). This clearly distinguishes it from sibling tools like list_devices and list_zones, and from run_schedule which executes rather than lists.

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

  Usage Guidelines2/5

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

  No explicit when-to-use guidance is given. There is no mention of when to choose list_schedules over get_status, list_zones, or run_schedule, and no exclusions or alternatives are named. The only usage signal is the verb 'List,' which implies a query operation.

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

• get_statusA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It does explain what the tool reports (online, paused, rain delay, watering), which is useful. However, it does not explicitly state that it is a read-only operation or mention any side effects, permissions, or limitations.

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

  Conciseness5/5

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

  The description is two sentences with no filler. The core status information is front-loaded, and the closing phrase adds differentiation without redundancy. Every word earns its place.

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

  Completeness3/5

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

  For a simple status tool with no output schema, the description lists the key return categories, which is helpful. However, it omits any explanation of the 'device' parameter, and since there is no output schema, the return structure is only partially specified. The tool is simple enough that this is a moderate gap rather than a fatal one.

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

  Parameters1/5

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

  The schema has one parameter, 'device', with 0% description coverage, and the description never mentions it. The description does not explain what 'device' refers to, whether it is required, or what happens when it is null. The schema title 'Device' is the only hint, which is insufficient.

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

  Purpose5/5

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

  The description clearly identifies the resource (a controller) and the specific information returned: online status, on/paused state, rain sensor/delay, and current watering activity. It also distinguishes itself from siblings with 'The one call for "what's my sprinkler doing"', making its purpose unmistakable.

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

  Usage Guidelines4/5

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

  The phrase 'The one call for "what's my sprinkler doing"' gives clear context for when to use this tool. It does not explicitly name alternatives or state when not to use it, but the usage context is strong enough for an agent to route status queries here.

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

• start_zonesA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the zones water 'one after another in the order given,' which is a key behavioral trait, but it does not mention potential side effects, error handling, or what happens upon completion. The disclosure is helpful but incomplete.

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

  Conciseness5/5

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

  The description is two sentences with no extraneous information. It front-loads the purpose and includes the essential parameter details. Every word earns its place.

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

  Completeness2/5

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

  Given the tool's moderate complexity (multi-zone sequencing), the lack of annotations, and no output schema, the description is incomplete. It does not mention when to use this over siblings, what happens after the sequence, or any error/edge-case behavior. An agent cannot fully determine the appropriate context without additional information.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It explains the structure of the zones array ('zone' and 'minutes'), which is critical because the schema only defines items as objects with additionalProperties. However, the optional 'device' parameter is not described at all, leaving its meaning and usage unclear.

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

  Purpose5/5

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

  The description states a specific verb ('Run') and resource ('multiple zones') and clarifies the behavior ('in sequence'), which distinguishes it from sibling tools like start_zone (singular) and run_schedule (predefined schedule). The purpose is immediately clear.

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

  Usage Guidelines3/5

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

  The description implies usage for multiple zones in a specific order but does not explicitly mention when to use this tool instead of alternatives such as start_zone or run_schedule. No exclusions or comparative guidance are given, so an agent must infer the intended use.

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

• list_devicesA
  3.7/5.0
  Behavior3/5

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

  With no annotations to rely on, the description must communicate behavior, and it does mention the return contents ('status and zone summary'). It does not cover potential side effects (likely none) or any caveats like pagination or authentication, but the simple read-only nature is inferable. It provides some behavioral context beyond an empty description.

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

  Conciseness5/5

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

  The description is a single, concise sentence that includes the action, target, scope, and key return elements. Every word contributes meaning without redundancy or unnecessary detail.

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

  Completeness4/5

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

  For a parameterless list operation with an output schema defined, the description provides sufficient insight into expected results ('status and zone summary'). It does not mention pagination, limits, or error cases, but these are not critical given the tool's simplicity and the existence of an output schema.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema coverage is 100% (vacuously). According to the rubric, a baseline of 4 is warranted when there are no parameters, and the description does not need to compensate for undefined arguments.

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

  Purpose4/5

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

  The description uses a clear verb 'list' and identifies the resource 'Rachio controllers' with the scope 'on the account' and the included fields 'status and zone summary.' It is distinct from a tautology, though it does not explicitly compare against siblings like `get_status`.

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

  Usage Guidelines3/5

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

  The description implies usage by stating the resource and action, making it evident this is for retrieving a list. However, it does not explicitly state when to choose this over alternatives such as `get_status` or `list_zones`. The guidance is implicit rather than prescriptive, earning a middle score.

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

• list_zonesA
  3.8/5.0
  Behavior3/5

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

  Without annotations, the description carries the full burden of behavioral disclosure, and it makes a genuine attempt: 'every' implies no pagination, and the parenthetical enumerates the return fields. However, it omits how the optional device parameter interacts with the scoping phrase 'on a controller'—must one device be specified, or does it default to all? It also doesn't disclose error behavior or whether the list is sorted. Adequate for a simple read operation, but not rich in caveats.

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

  Conciseness5/5

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

  A single, front-loaded sentence with a clear verb first. The parenthetical efficiently conveys the output fields without embedding them awkwardly in the prose. No wasted words; every token contributes meaning.

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

  Completeness4/5

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

  The presence of a separate output schema (noted in context signals) means the description doesn't need to specify return types, and it wisely uses the parenthetical to name the fields (number, name, enabled state) that any agent would need to know they can expect. The single optional `device` parameter is its only real complexity, and while the description hints at its purpose ('on a controller'), it could add a brief note on what omitting it does (e.g., default to all controllers) without bloating the text. For a tool this simple, this is close to as complete as it needs to be.

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

  Parameters3/5

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

  Schema description coverage is 0%, meaning the JSON Schema offers only the parameter's name ('device'), type (string/null), and default (null) with no free-text explanation. The description's word 'controller' provides the sole semantic bridge connecting the `device` parameter to the conceptual domain of zones, hinting that this is likely the controller identifier to query. Yet the description never explicitly names `device` or explains what happens if it's null, so the compensation is partial.

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

  Purpose5/5

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

  The description uses a specific verb ('List') plus a concrete resource ('every zone on a controller') and includes a parenthetical specifying the returned fields (number, name, enabled state). This makes it immediately distinguishable from siblings like list_devices and list_schedules, which follow a similar naming pattern but operate on different resources. The word 'every' reinforces the exhaustive scope without ambiguity.

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

  Usage Guidelines3/5

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

  Usage is implied: an agent can infer this is the right tool when it needs zone information, especially before starting zones via start_zone or start_zones. However, there's no explicit statement of when NOT to use it or which alternative to choose (e.g., no 'for device inventory use list_devices'). The description provides the 'what' but not the conditional 'when/why' that separates a 4 from a 5.

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

• set_device_powerA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It accurately states the key effect (turning off pauses all scheduled watering until turned back on), which is the primary behavioral trait. However, it does not mention details like whether turning on resumes previous schedule settings, device scoping, or response format, but for a simple boolean toggle these are minor gaps.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the action, and contains no redundant phrases. It efficiently conveys the core function and the effect of turning off, with zero wasted words.

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

  Completeness3/5

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

  For a simple boolean toggle tool, the description covers the main behavior but omits the meaning of the device parameter (e.g., whether it applies to all devices when null). It also does not describe return values or errors, though no output schema exists. Given the simplicity and the partial parameter explanation, it is adequate but not fully complete.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It explains the 'on' parameter's meaning by mapping on to 'standby off' and off to 'standby on', which is helpful. However, the optional 'device' parameter is completely unexplained, leaving its purpose and behavior ambiguous. The description adds value for one parameter but fails to cover the other.

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

  Purpose5/5

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

  The description clearly states the action: turning a controller's automatic schedules on or off, with the mapping between on/off and standby states explicitly given. It also explains the effect of turning off (pausing scheduled watering), which differentiates it from sibling tools like start_zone or run_schedule that control specific watering actions.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool (to enable/disable automatic scheduling), but it does not explicitly state when to prefer this over alternatives like stop_watering (which stops current watering) or set_rain_delay. No exclusions or alternative tool names are mentioned, so guidance is implied rather than explicit.

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