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

The annotations already declare readOnly, idempotent, non-destructive behavior, so the bar is lower, and the description still adds two non-obvious traits: a per-machine 30-second real-call throttle and cached responses on faster calls. It also clarifies the semantics of an empty result, which is a genuine behavioral edge case. It stops short of saying whether cached answers are distinguishable from fresh ones or how long the cache window is.

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 zero filler: what it returns, how to read an empty result, and the rate-limit/caching rule. The primary definition is front-loaded ahead of the caveats.

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 return shape, and it does at a high level (error code plus since-when) along with empty-list semantics and throttling behavior. What remains unspecified is the exact response structure (array vs. wrapper) and whether error severity or description fields accompany the code.

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 'serial' parameter already carries a description pointing at hobart_list_machines, so the schema does the heavy lifting. The description adds nothing about serial format, case sensitivity, or what happens with an unknown serial. 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 names a specific resource and scope: active errors on a dishwasher, including error code and start time. This is clearly distinct from sibling tools like hobart_get_temperatures or hobart_machine_overview, though it never explicitly contrasts itself with them. The purpose is unambiguous, but the differentiation is left implicit.

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

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

Usage is implied rather than stated: the tool reports active errors, and the 'empty list means no active error was reported, not that the machine is running' note helps interpret results. Missing is any statement about when to reach for this versus hobart_machine_overview or hobart_get_machine_data, or any prerequisite such as needing a serial from hobart_list_machines.

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, but the description adds the crucial non-obvious trait: Hobart only refreshes after power-off or shortly before midnight, so the payload is stale by design. That freshness caveat materially changes how an agent interprets and reports the data, and it is exactly the kind of behavior annotations cannot express.

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

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

Two sentences, no filler, with the payload contents front-loaded and the staleness caveat placed where it will be read before calling. 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 enumerates the returned sections, and the refresh caveat covers the main interpretive risk. Minor gaps remain: units for consumption values and the potential size of the hygiene protocol (one entry per wash cycle) are 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?

Only one parameter, and the schema already documents it at 100% coverage, including the pointer to hobart_list_machines for obtaining the serial. The description adds nothing further about the serial, so the baseline 3 applies.

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

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

The description names the specific resource (daily dishwasher data) and enumerates its three sections: consumption metrics, C0xx counters, and the per-cycle hygiene protocol. This distinguishes it in practice from hobart_get_temperatures and hobart_get_active_errors, though no sibling is named 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 gives a clear selection rule: this returns the last completed day, not the current state, so an agent needing live readings knows to look elsewhere. It stops short of naming the alternative tool for real-time data.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: a 60-second per-machine real-call limit and that faster calls silently return cached data — a caveat an agent otherwise could not know.

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 waste. Return contents are front-loaded and the operational caveat follows immediately after.

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 enumerates the returned fields and their unit, and covers the rate-limit/caching behavior. It stops short of explaining the shape of 'last program run' (name vs timestamp vs status), a minor remaining gap for a tool of this simplicity.

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 `serial` parameter already documents that it comes from hobart_list_machines. The description adds no further meaning about the parameter, so the baseline 3 applies.

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

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

The description names the specific resources returned — wash tank (A270) and rinse (A283) temperatures in °C plus the last program run — so the agent knows exactly what this yields. It does not, however, distinguish itself from siblings like hobart_get_machine_data or hobart_machine_overview, which plausibly overlap.

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

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

Usage is only implied: an agent infers it should call this when it wants temperature readings. There is no explicit when-to-use statement and no routing to or away from the overlapping siblings hobart_get_machine_data and hobart_machine_overview.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds value the annotations don't: the exact payload fields returned, which matters because there is no output schema. It stops short of stating result limits or whether the list is paginated, leaving a minor gap.

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

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

Two short sentences: the first defines the resource and its return fields, the second delivers the usage rule up front. Nothing is redundant and nothing is 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?

With no output schema, the description carries the burden of telling the agent what comes back, and it does so by listing four concrete fields. Combined with the entry-point guidance and existing annotations, an agent has everything needed to invoke it correctly.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The account scoping mentioned ('registered on this account') is useful framing even though no parameter exists for it.

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

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

States a specific verb (Lists) and resource (Hobart dishwashers registered on this account), then enumerates the returned fields: serial number, machine type, protocol version, machine clock. This clearly distinguishes it from data-oriented siblings like hobart_get_machine_data or hobart_get_temperatures.

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?

'Start here: every other tool needs a serial number' explicitly names when to use this tool and why, and implicitly routes the agent away from every sibling until a serial is obtained. That is an explicit entry-point rule rather than an inferred one.

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 safety is covered. The description adds real value by disclosing the composite nature of the call (errors + temperatures + consumption in one shot) and implying a single-round-trip cost advantage, though it does not discuss freshness or limits of the aggregated 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 sentences, both load-bearing: the first defines the aggregated payload, the second routes the agent away from the three detail tools. Front-loaded with the core purpose and 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?

No output schema exists, but the description effectively enumerates the return categories (errors, temperatures, consumption), which is enough for an agent to know what to expect. Annotations carry the safety profile, so the only minor gap is the precise shape of the aggregated 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 coverage is 100% and the single parameter is documented in the schema as the serial from hobart_list_machines. The description only refers to 'machine X' and adds no syntax or format detail beyond the schema, 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 and resource ('One-call health check of a dishwasher') and enumerates exactly what it returns: active errors, last wash/rinse temperatures, daily consumption. The reference to 'the three detail tools' makes clear it aggregates hobart_get_active_errors, hobart_get_temperatures, and the consumption data, distinguishing it from siblings.

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

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

Explicitly says 'Prefer this to calling the three detail tools separately when the question is "how is machine X doing"', naming the alternative and the exact condition that selects this tool. Nothing is left to inference about when to prefer the aggregate over the individual calls.

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, openWorld, so safety is covered; the description adds useful behavior beyond that by disclosing that it exercises the configured account's sign-in, implying credentials must be set up. It stops short of describing the outcome/return shape, which matters for a diagnostic 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 sentences and zero filler: the first states what is verified, the second states the usage constraint. The condition that selects the tool is front-loaded after the purpose.

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

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

For a zero-parameter, no-output-schema health check, the description gives enough to call it correctly and interpret its intent. The only gap is the absence of any statement about what a result looks like (pass/fail, error text), which is the remaining ambiguity an agent would face.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline of 4 applies and the description correctly does not waste space on inputs.

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 (checks) and a specific resource (Hobart Cloud-to-Cloud API reachability plus account sign-in), which clearly distinguishes this diagnostic from the sibling data-retrieval tools like hobart_get_machine_data or hobart_get_active_errors.

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 names the trigger condition ('only when another tool fails') and the goal ('whether the problem is the connection'), which also acts as an exclusion against routine/periodic use. An agent has no ambiguity about when to call this versus a sibling.

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