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

No annotations are provided, so the description carries the full burden. It does disclose the shape of what comes back (IDs, names, connection status, module list with field names), implying a read-only enumeration, but says nothing about volume, pagination, or whether the list is scoped to a target/connection.

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 with zero waste: purpose and scope first, then return fields, then usage ordering. Every clause earns its place 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 usefully enumerates the returned fields, and with no parameters there is nothing else required to invoke it. The remaining gap is the unexplained overlap with wem_get_device_status and any guidance on result size.

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 and there is no parameter semantics to compensate for. The description correctly implies the call needs no input.

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 all WEM devices") and enumerates the return contents: device IDs, names, connection status, and module list with Index/Type/Name. It is mostly distinguishable from siblings, but it returns connection status while a sibling named wem_get_device_status exists, and the description never explains how the two differ.

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 this first to discover deviceId, moduleIndex, and moduleType needed for other tools" gives explicit sequencing and the downstream purpose, which is strong guidance for a zero-param discovery tool. It stops short of naming the alternatives it feeds into or saying when a more targeted sibling should be used instead.

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?

No annotations are provided, so the description carries the burden. 'Get' implies a non-mutating read and 'connection/online status' discloses the core returned concept, but there is no mention of permissions, status value semantics (online/offline/unknown), freshness, or behavior for unknown device IDs.

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

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

A single front-loaded sentence with zero waste. It is efficient, though slightly sparse given the absence of 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?

For a one-parameter read tool with no output schema, the description covers what is fetched but not the shape or meaning of the status values, nor error behavior for invalid device IDs. Adequate minimum but with clear 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 100% and the single deviceId parameter already documents its source ('from wem_get_devices'). The description adds no further parameter meaning, so the schema does the heavy lifting and 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 ('Get') and resource ('connection/online status of a specific device'), which is clearly distinct from wem_get_devices (which lists devices) and the parameter tools. It doesn't explicitly name the sibling boundary, but the scope 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?

Usage is implied by 'a specific device', suggesting single-device status checks rather than bulk listing. There is no explicit when-to-use/when-not guidance or named alternative for listing devices, leaving routing to be inferred 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?

No annotations exist, so the description carries the full burden. It does disclose the key behavior that this is an aggregate single-call read returning every module's parameters and current values, which hints at a large response. It omits whether the payload is truncated/paginated, permission requirements, and cost of a full sweep.

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 capability and the "single call" qualifier before the usage note. The second sentence is mildly redundant but does add decision context rather than 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?

With one required parameter, no annotations, and no output schema, the description usefully compensates by describing what comes back (all modules, all parameters, current values). It is nearly complete for a simple read tool; only pagination/size expectations and a sibling comparison 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?

Schema coverage is 100%, and the schema already documents that deviceId comes from wem_get_devices, so the schema does the heavy lifting. The description adds no further meaning about the parameter, which is the expected baseline for fully documented single-parameter tools.

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 an overview of a device) and defines scope precisely: all modules with all parameters and current values in one call. It implicitly contrasts with the narrower sibling readers like wem_get_parameters and wem_read_parameters, but never names them, so the differentiation is inferred rather than stated.

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

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

"Useful for getting a full picture of the heating system state" implies when to reach for it, but no explicit when-not condition or named alternative is given. An agent must guess whether to call this instead of wem_get_devices + wem_get_parameters or wem_get_device_status.

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?

No annotations are provided, so the description carries the full behavioral burden. It helpfully enumerates the returned metadata fields and implies a read-only discovery operation, but never explicitly states read-only/non-destructive semantics, permission requirements, or pagination/response shape for large modules.

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 capability and followed by the workflow guidance. No filler, no repetition of 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?

With no output schema and no annotations, the description does the necessary work by listing the returned metadata fields and the intended discovery workflow. Minor gaps remain around read-only guarantees and response size, but an agent has enough to call 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%, and each parameter already documents its provenance (deviceId from wem_get_devices, moduleType/moduleIndex from the device's Modules array). The description adds no additional parameter meaning beyond what the schema provides, 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 ('Get metadata for all parameters of a module') and enumerates exactly what the metadata contains (IDs, names, writable flag, data types, min/max, enum options). It implicitly distinguishes itself from value-reading siblings via 'before reading values', though it never names wem_get_parameters or wem_read_parameters directly.

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 usage context: 'Use this to discover available parameters before reading values', which establishes the discovery-before-read workflow. It does not explicitly exclude alternatives or explain when to prefer wem_get_parameters or wem_get_writable_parameters, which matters given seven 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?

With no annotations, the description does real work by disclosing that this is a composite operation bundling a refresh, not a pure cached read — that is meaningful behavioral context an agent won't get from the schema. It stops short of saying whether the refresh causes a round-trip to the device, what happens on communication failure, or any permission/latency implications.

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 purpose, then the operational nuance, then the return shape. Every sentence earns its place and 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?

With no output schema, the description correctly compensates by enumerating the return fields (names, values, units, writable flags). It is nearly complete; it could still say what the values look like for suppressed/invalid params or how errors surface, but nothing critical to correct invocation is missing.

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

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

Schema description coverage is 100%: all three params are documented with provenance pointers back to wem_get_devices and the device's Modules array. The description adds no parameter-level semantics beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get all parameters of a module with current values') and the composite nature of the call, which implicitly separates it from the granular siblings wem_get_parameter_meta and wem_read_parameters. It never names those siblings, so the differentiation is left partly 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?

'Combines metadata + refresh + read into one call' implies this is the one-shot alternative to the granular tools, so the when-to-use is implied. There is no explicit statement of when NOT to call it (e.g., when only metadata is needed, prefer wem_get_parameter_meta) and no prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the full burden. It does well to disclose the return shape (current values, min/max ranges, enum options) and implies a non-mutating read via 'get', but says nothing about prerequisites, whether device state/busy state matters, or error behavior.

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

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

Three short sentences, front-loaded with the scoping qualifier and the return content. No filler, though the parenthetical duplicates the word 'writable' already present in the name.

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, and the description compensates by naming exactly what the response contains (values, min/max, enum options). With parameters fully covered by the schema, this is close to complete for a simple read tool; only permissions/prerequisites are 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%, so all three parameters are already documented; the description adds nothing about deviceId, moduleIndex, or moduleType, including how to discover a valid moduleType or moduleIndex. Baseline 3 applies since the schema does 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 (get) and a precisely scoped resource (only writable parameters of a module), with a parenthetical clarifying what 'writable' means. It implicitly distinguishes itself from the broader parameter-reading siblings by the word 'only', though it never names wem_get_parameters or wem_read_parameters directly.

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?

'Useful to see what can be adjusted' implies a use case but gives no explicit when-to-use or when-not-to-use guidance relative to the sibling tools that also read parameters (wem_get_parameters, wem_read_parameters, wem_get_parameter_meta). The agent must infer the routing itself.

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?

With no annotations, the description still discloses a non-obvious behavioral trait: it refreshes data from the device before reading, implying device I/O and added latency versus a cached read. It does not cover failure behavior, permissions, or whether the refresh has side effects on the device.

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 purpose and then the refresh behavior, with no filler. There is mild redundancy in 'Read current values ... then reads' but it costs little.

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?

Four required parameters, no annotations, and no output schema mean the description carries the burden of explaining results, yet it says nothing about what is returned (values keyed by parameter ID? partial failures for invalid IDs?). The refresh disclosure helps, but the return-shape gap leaves it 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 100% and every property already documents its source tool (wem_get_devices, wem_get_parameter_meta), so baseline 3 applies. The description adds no meaning about the parameters themselves, e.g. whether parameterIds must come from the same module or how moduleType interacts with parameterIds.

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 current values for specific parameters') with a scoping qualifier ('specific' vs all) that implicitly separates it from wem_get_parameters. It never names that sibling explicitly, so the differentiation must be inferred from the trailing 'instead of all' clause.

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 you only need specific parameter values instead of all' gives a clear selection condition against the bulk-read alternative. It stops short of naming wem_get_parameters or stating exclusions such as when a full snapshot is preferable.

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?

No annotations exist, so the description carries the full burden. It discloses the writable-only constraint and the need to pre-validate ranges/enums, which is meaningful. It says nothing about whether the write is immediate, persistent across reboots, what error surface appears for out-of-range values, or whether it is reversible.

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

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

Two short sentences, zero filler, with the constraint and the prerequisite check front-loaded before any elaboration. Nothing is repeated from 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 5-required-parameter mutation tool with no annotations and no output schema, the description covers the essential guardrails (writable check, meta lookup) but leaves open units, what the call returns, and the stringValue/numericValue decision. Adequate, not complete.

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

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

Schema coverage is 100%, so the schema already documents all six parameters, giving a baseline of 3. The description adds no field-level meaning beyond the example value, and in particular never explains the numericValue vs. stringValue selection that an agent must decide for enum/text parameters.

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?

"Set a parameter value" names a specific verb and resource, with a concrete example (target temperature) that makes the abstraction tangible. It does not explicitly contrast itself with sibling read tools like wem_read_parameters, but the write/read split is inferable from the name and text.

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 hard precondition ("Only works for writable parameters") and a sequencing instruction ("Check wem_get_parameter_meta for min/max values and enum options first"). That is real routing guidance, though it never names the alternative write path or says what to do if the parameter turns out non-writable.

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