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

Adds substantial behavior beyond the annotations: membership and fresh-state pre-checks, a single write followed by independent readback, no auto-retry on uncertain outcomes, and the caveat that a matching cloud readback does not prove physical execution. This meaningfully enriches the annotated non-idempotent, open-world mutation profile.

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

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

The core action and the at-least-one-setting constraint are front-loaded, then each subsequent sentence delivers a distinct operational rule with no filler. Dense but 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?

For a non-idempotent mutation tool with an output schema present, the description supplies all the missing context an agent needs: preconditions, write/readback protocol, retry policy, and the limits of cloud-confirmed success. Nothing essential is left ambiguous.

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

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

With 0% schema description coverage, the description compensates well: it clarifies power as an explicit boolean, the 17–30°C / 0.5°C temperature policy, the cross-field rule that mode/fan/temperature do not enable power, and the require-at-least-one-setting constraint. It leaves device_id semantics and the mode/fan option meanings to the schema's enums.

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+resource+scope: 'Change only requested fields on an account-owned AC', which pins partial-update semantics and the ownership constraint. This cleanly separates it from every sibling (login/logout/list_devices/get_status/get_capabilities), none of which mutate device state.

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 operational context: at least one setting is required, power is an explicit boolean, and mode/fan/temperature never implicitly turn power on. It does not, however, name or route away from any sibling tool (e.g. when to read state first via meiju_get_status), so the when-not 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.

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses meaningful behavioral caveats: the profile is 'experimental', fields are 'observed' rather than guaranteed, and unknown fields must not be treated as defaults. This is exactly the kind of data-trust context annotations cannot carry.

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

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

Two short sentences with no filler, and the most important caveat is front-loaded. The phrasing is terse to the point of being cryptic, but nothing is padded.

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?

An output schema exists, so return values need not be explained, and the description usefully frames how to interpret them. However, for a read tool with a 1-param surface it still omits the actual purpose and any routing guidance, leaving the definition only minimally adequate.

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

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

Schema description coverage is 0% for the single required device_id parameter, and the description says nothing about it (format, source, or constraints). With low coverage the description was expected to compensate and does not.

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

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

The name says 'get_capabilities' but the description never says it returns device capabilities; instead it negates them ('not guaranteed hardware capabilities') and uses jargon like 'candidate protocol profile'. An agent cannot easily tell what this returns or how it differs from the sibling meiju_get_status.

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 indication of when to call this versus meiju_get_status, meiju_list_devices or meiju_control. The only guidance is about interpreting results ('unknown fields must not be treated as defaults'), not about tool selection.

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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses two important behavioral traits: fields may be absent and remain 'unknown', and the cloud data may be cached (i.e., stale). That is genuine added context for interpreting results and avoiding wrong conclusions.

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 no filler, and the core purpose is front-loaded before the caveats. 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?

An output schema exists, so return structure need not be described. With caching and unknown-field caveats covered, the definition is nearly complete; only the per-device acquisition route (device_id source) is left implicit.

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

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

Schema coverage is 0%, so the description carries the burden. 'Selected AC' hints that device_id identifies an AC unit, but it adds no format, source, or acquisition guidance beyond what the string 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 ('Read') and resource ('AC's cloud status'), which clearly separates it from meiju_control (mutation) and meiju_get_capabilities. It does not explicitly name a sibling to differentiate against, but the read/status framing is unambiguous.

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

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

No indication of when to prefer this over meiju_get_capabilities, meiju_list_devices, or a status field returned elsewhere. The agent must infer that this is the per-device status lookup from the name alone.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real behavioral context beyond that: only the experimental AC profile supports controls (implying limited capability), and device_id is opaque, which warns against parsing it.

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

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

Two short clauses with the primary action front-loaded and no filler. It is efficient, though the second clause reads as a disconnected note that could be tied more explicitly to the returned devices.

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?

An output schema exists, so return structure need not be explained, and annotations cover the read-only safety profile. The description supplies the missing capability caveat; only a clearer link to downstream tools is absent.

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

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

The tool takes zero parameters, so the baseline is 4. The mention of opaque device_id refers to output identifiers rather than inputs, and adds mild value without contradicting the empty schema.

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

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

Specific verb+resource: 'Load account devices' clearly names what is returned. It partially differentiates from siblings by noting the experimental AC profile is the only one supporting controls, hinting at the meiju_control relationship, though it does not contrast against get_status or get_capabilities.

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 opaque device_id' implies this call is a prerequisite for later device-targeted operations, and the AC-profile note implies scope limits on downstream control. But there is no explicit when-to-use vs. siblings such as meiju_get_status or meiju_get_capabilities.

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 mark this as non-read-only yet non-destructive, and the description adds genuinely new behavioral facts: no SMS is sent, no contact with Meiju occurs, and an existing login is reused. Those disclosures matter for a tool whose name implies an authentication side effect. Remaining gaps are minor, e.g. session lifetime or what invalidates the local page.

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

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

Three short sentences, front-loaded with the action and immediately followed by the human-handling constraint. Every sentence earns its place; nothing is repeated from the schema or annotations.

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

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

An output schema exists, so return values like login_url need not be documented, and the description still names that field to tell the agent what to surface. Slightly incomplete in that it doesn't indicate the follow-up path for checking or completing login via meiju_login_status.

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

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

The tool takes zero parameters, so the schema carries no parameter semantics to compensate for and the baseline is 4. The description correctly spends no text on argument syntax.

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: it starts or reuses a local login page. The added 'does not itself send SMS or contact Meiju' cleanly separates it from an outbound authentication action. It stops short of naming its siblings (meiju_login_status, meiju_logout) to disambiguate further.

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 operating context: show login_url to the human, never request phone/OTP in chat, and reuse an existing login rather than starting a new one. It doesn't explicitly say what to do when a login already exists (e.g., check meiju_login_status first) or name the sibling that covers that path.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is low. The description still adds a behavioral trait beyond them: it explicitly states that no phone, code, or token is returned, pre-empting the assumption that a login-status tool would surface credentials.

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

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

Two short sentences, front-loaded with the purpose, with essentially no filler. The second sentence is mildly redundant given an output schema exists, which keeps it from a perfect score.

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

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

For a zero-parameter, read-only tool with a full output schema and covering annotations, the description supplies what an agent needs to call it correctly. Only the login-flow sequencing guidance is absent, which is a minor 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?

The tool takes zero parameters, so the baseline is 4 per the rubric. There is no parameter surface for the description to explain, and the schema correctly declares an empty, closed object.

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

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

States a specific verb ('Check') and a specific resource/state ('whether the human has completed local login'), which clearly separates it from meiju_login (initiates the flow) and meiju_get_status (device status). The distinction is conveyed by the wording itself, 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?

The description never says when to call this tool, whether it is meant to be polled after meiju_login, or how it relates to meiju_login/meiju_logout. An agent must infer the login-flow context entirely from the name.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=false and destructiveHint=false; the description goes beyond them by disclosing that a shared saved login is also forgotten and that pending login pages are invalidated, plus explicit non-effects. It still omits prerequisites such as needing an active session and whether re-login is required afterward.

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

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

Two short sentences, front-loaded with the core effect and followed by the scope limits; every clause carries information. Slightly clipped phrasing with the parenthetical '(if shared)' but no wasted text.

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?

An output schema exists, so return values need no explanation, and the critical risk information (what is and is not invalidated) is present for this simple 0-param mutation. Only the session prerequisite is unstated, which is a minor 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?

The tool takes zero parameters, so the schema (100% coverage) fully carries parameter semantics and the description has nothing to add. Baseline 4 applies for a no-parameter tool.

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

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

The description gives a specific verb+resource ('Forget this session and its saved login') and scopes the resource further with 'invalidate pending login pages'. It clearly distinguishes the operation from adjacent concerns (device unbinding, the official app's login, AC settings) even though it does not name sibling tools like meiju_list_devices by name.

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

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

The description's exclusion sentence effectively tells the agent when NOT to reach for this tool: it will not unbind devices, revoke the official app login, or change AC settings. That is strong negative routing, but it never states the positive trigger (end/clear the current session) or names a concrete alternative tool for those other tasks.

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