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

With no annotations, the description carries the full burden and does disclose two important behaviors: sensitive values are redacted, and the return includes a source/result pair plus an explanation when the web interface responded. It omits error behavior for unknown names, permission requirements, and confirmation that the operation is read-only beyond the verb 'Read.'

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

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

Three short sentences, front-loaded with the core action and with zero filler. The final clause about the web interface answering is slightly cryptic but still earns its place by describing return behavior.

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 single-parameter read tool with no output schema and no annotations, the description covers the essentials: what it reads, what is redacted, and roughly what is returned. Missing details on failure modes and the meaning of 'source' keep it from being fully complete.

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

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

Schema coverage is 0%, so the schema only declares a bare string 'name.' The description partially compensates by clarifying that it is a single named value and by pointing to list_reads for valid names, but it does not describe the expected naming format or case sensitivity.

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 one named value from the Deco,' which is clear and actionable. It implicitly distinguishes itself from get_router_data_unredacted via the redaction note and from list_reads via the pointer, though it never names the unredacted sibling explicitly.

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

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

Provides a prerequisite by directing the agent to list_reads to discover valid names, which is useful usage context. However, it does not explicitly state when to choose this tool over get_router_data_unredacted or router_snapshot, leaving selection to inference.

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 carries the full burden and does disclose the key behavioral trait: output contains live credentials and must not be persisted without asking. It does not state read-only semantics, permission requirements, or what the response looks like, which leaves a modest gap for a credential-returning tool.

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 differentiator against the sibling, then the safety constraint. Every clause earns its place with no repetition of structured fields.

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 or annotations, the description covers purpose, selection criteria, and handling caution adequately. The remaining gap is the meaning of 'name' and any hint about returned structure, though the get_router_data sibling likely fills that in.

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% and the single 'name' parameter is undocumented in both schema and description. The description never clarifies whether 'name' is a router label, a network identifier, or something else, and adds no format or constraint hints to compensate.

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 action (retrieve router data) and a precise scope modifier (unredacted, including Wi-Fi passwords and a WireGuard private key). It explicitly anchors against the sibling get_router_data, so an agent can tell the two apart without opening either schema.

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

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

Gives an explicit gate: 'Only use this when the user specifically needs the secret.' That is a when-to-use rule plus an implicit when-not (use the redacted sibling otherwise), and it names the alternative surface (get_router_data) in the first clause.

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 behavioral burden. It does disclose a non-obvious trait: the output also tells you which reads the web-interface fallback can serve, which is genuine value beyond the schema. However, it says nothing about whether the list is static or device-dependent, its shape (flat names vs. objects), or whether it is safe/cheap to call repeatedly.

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

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

Two sentences, front-loaded with the core claim and followed by the actionable routing hint. The parenthetical category list is long but earns its place as a preview of output in the absence of an output schema, though the trailing '...' makes it slightly open-ended.

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 must convey enough about the response. It conveys the subject matter and the fallback annotation but not the structure of each entry (identifiers, flags, nesting), which an agent needs to consume the result without guessing.

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 description correctly implies a parameterless discovery call and requires no argument explanation.

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 resource (every read the router exposes) and previews the categories returned (client list, Wi-Fi config, QoS, port forwarding, DHCP, VPN, firmware), so an agent knows it is a catalog of read operations rather than a data fetch. It partially differentiates from get_router_data ('Use get_router_data to read one'), but never contrasts itself with the sibling list_writes.

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

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

It gives an explicit routing rule: call this to discover reads, call get_router_data to actually read one. That removes the main ambiguity. It stops short of stating when-not to use it (e.g., if you already know the read name) or how it relates to the fallback path it mentions.

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 the reliability model: verified means a live read-back, upstream means captured but not retested, noop means proven inert, and inferred means a guess. It also says each entry carries a note, though it does not state side effects, permissions, or rate limits.

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

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

A single front-loaded sentence introduces the resource and then defines the four statuses; every clause is needed to interpret the output. No filler or redundant restatement of 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?

For a no-parameter list tool with an output schema, the description supplies enough context to understand what the list contains and what the status labels mean. It could add an explicit read-only/side-effect statement, but the output schema can carry return-value detail.

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

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

There are zero input parameters, so parameter semantics are not a concern; baseline 4 applies. The description adds no parameter details, which is appropriate for a no-argument listing 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 opening clause states it enumerates every write the server can attempt, and the parentheticals define the verification statuses attached to each write. It implicitly distinguishes itself from list_reads by scoping to writes, though it does not name that sibling.

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: the all-writes scope suggests calling it to inventory available writes, and the status labels suggest using it to assess reliability. It never states when to choose this over list_reads or a specific write tool.

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 carries the burden and usefully discloses that it makes no router contact and explains the lockout concept. Still, it does not clarify freshness, caching, read-only implications, or the exact return shape, which leaves meaningful behavioral gaps.

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. It front-loads the core status question and adds only the important 'No router contact' operational detail.

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

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

For a zero-parameter status tool, the description gives enough context to understand what is returned: lockout state and last lockout outcome. Without an output schema, the exact response format is not specified, but the low complexity keeps this from being a major 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 has zero parameters, so parameter semantics are not applicable and the baseline is 4. The description does not need to explain any input values.

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

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

The description states a specific status query: whether the router is still applying a write via a locked control port, plus the outcome of the last lockout. It is clear what the tool reports, but it does not explicitly distinguish itself from siblings such as list_writes or router_snapshot.

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 the name and description: check lockout status when investigating write application state. However, there is no explicit guidance on when to use this versus list_writes or router_snapshot, and no stated 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?

With no annotations, the description carries the behavioral burden and does add useful context by disclosing that it performs 'two reads, with the web-interface fallback.' It does not explicitly state read-only safety, permissions, or fallback conditions, but the operational behavior is more transparent than a bare 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?

The description is a single dense sentence that front-loads the core purpose and enumerates returned fields efficiently. It is appropriately sized, though the long parenthetical listing makes it slightly harder to scan than a more structured breakdown.

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 fully enumerates the node and client fields an agent would receive. It gives enough return-value detail to understand the response shape without unnecessary repetition.

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 score is 4. The description correctly does not invent parameter details, and no input parameters require additional semantic explanation.

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 clearly identifies the resource and contents: a mesh overview with detailed per-node and per-client fields. It is specific about what data is returned, but it does not explicitly differentiate itself from sibling tools such as get_router_data or router_snapshot.

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

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

The phrase 'at a glance' implies a summary use case, but the description never states when to prefer this tool over alternatives like get_router_data or router_snapshot. Usage is only implied, not explicitly guided.

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 carries the full burden and does well: it quantifies ~70 reads, the 1 s pacing, a duration over a minute, and the load on the router. It does not describe the shape or arrangement of the returned values, which matters for a bulk read.

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 scope and immediately followed by the cost and the alternative. 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?

Cost, pacing and duration are covered, which is what an agent most needs before invoking a minute-long bulk read. The absence of an output schema leaves the return contents ('every known value') underspecified, a minor remaining 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 there is nothing for the description to clarify; baseline 4 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 scope (read every known value in one pass) and explicitly positions it against the sibling get_router_data, so an agent can distinguish the two without inspecting either schema.

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

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

Names the alternative (get_router_data) and the reason to prefer it ('what you actually need'), which routes the agent away from over-reading. The positive case for using this tool – needing the complete state at once – is only implied by 'every known value'.

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 at all, the description carries full burden and does it well: it discloses the refusal behavior for unverified writes, the required user confirmation, the ~60-90 s router lock side effect, and the requirement to report the read-back rather than just 'success'. These are exactly the operational traits an agent cannot infer from the 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?

Dense and front-loaded: the core action comes first, then the workflow, then the guardrail, then the return contract and side effect. Slightly fragmented by parentheticals, but every sentence carries information an agent needs.

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 three-parameter mutation tool with no annotations and no output schema, the description covers the mutation workflow, the safety gate, the post-write side effect, and what is returned ('after' read-back) — enough to invoke it correctly and report results faithfully. Nothing critical is left to guess.

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%, so the description must compensate, and it mostly does: 'name' is illustrated (led_set, led_schedule), 'params' is defined as the whole object as read from the matching read with the change applied, and allow_unverified is explained behaviorally. It never explicitly maps these to the parameter names, so an agent must infer the correspondence.

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 ('Write a setting') and points to list_writes for the valid settings, which distinguishes it from read-side siblings like get_router_data and list_reads. It stops short of naming the other siblings it competes with, so identification is solid but not fully framed.

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

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

Gives a concrete read-modify-write workflow ('read led_schedule, flip enable_night_mode, send it to led_set') and an explicit gate: refuses unverified writes unless allow_unverified=True, and the user must be asked first. It doesn't contrast with read-only alternatives (e.g., when a snapshot is preferable), but the when-to-use path is clear.

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