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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds that it reports on access-control enablement, blocked devices (with reasons), and active schedules—useful content beyond the annotations. It does not, however, mention whether the data is real-time vs. cached or any auth requirements, which is a mild gap given the annotation baseline.

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 sentence with no filler. It front-loads the primary question (whether Access Control is on) and then lists the other data points. Nothing is extraneous.

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. The description covers the key information categories an agent would want. It falls short of 5 only because it doesn't route to alternatives or clarify that this is a read-only snapshot, though annotations cover the safety aspect.

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?

Zero parameters, so baseline is 4. The schema coverage is 100% and there are no params to document; the description appropriately does not discuss inputs. No penalty, no extra credit possible.

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 enumerates the facts returned (Access Control on/off, blocked devices and reasons, active schedules), which implies a read of access-control status. However, the phrasing is a noun clause without a clear verb (e.g., 'get' or 'report'), and it doesn't explicitly differentiate from siblings like set_access, list_schedules, or apply_schedules. It's readable but could be mistaken for a state declaration rather than a data-retrieval tool.

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 when-to-use guidance, no alternatives mentioned. With siblings such as set_access, list_schedules, and device_history, an agent has no signal about when to prefer access_status over those. The description is purely descriptive of content, not prescriptive of use.

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 and idempotentHint=true, so the mutation/idempotency profile is covered. The description adds real value beyond them: times are local, the window can wrap across midnight (21:00 to 07:00), and enforcement depends on the watcher or apply_schedules — an agent needs that to know the block may not take effect immediately.

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?

Front-loaded with the core action in the first sentence, then a compact format note and a short enforcement note. No padding, though the day-format line and enforcement line are slightly terse relative to their importance.

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 described, and annotations cover safety. The description supplies the format and enforcement details an agent needs to call it correctly; only edge behavior (conflicts with existing schedules, permissions, what happens after end time) 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 description coverage is 0%, so the description carries the full burden. It documents the days grammar thoroughly (daily/weekdays/weekends/mon-fri/sat,sun) and gives a concrete start/end time format, and 'group, owner or device' implies what target accepts. Only 'name' goes unexplained, which keeps it out of 5 territory.

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 (Block) and resource (schedule) with the target scope (group, owner or device) and the temporal window, so the agent knows exactly what the tool creates. It does not explicitly differentiate itself from near-neighbors like pause_device or set_access, which also restrict access, so it stops short of a 5.

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 final sentence tells the agent the block is enforced by the background watcher or by apply_schedules, which is genuine operational context. However, it never states when to prefer this recurring schedule over one-off alternatives such as pause_device, so usage is implied rather than spelled out.

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 give readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds real context beyond them: it's an evaluation/apply step that modifies router allow/block state as a side effect, and it folds in manual overrides. That explains the write-nature and the idempotent nature. It doesn't discuss frequency, cost, or concurrency, but it adds meaningful behavior the annotations don't.

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?

One sentence, front-loaded with the action and ending with the effect. No filler; 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?

With no params and an output schema present, the return values needn't be explained. But given the crowded access/schedule sibling set and the fact that this is a state-mutating apply step, the description should say when to invoke it relative to add_schedule/remove_schedule/set_access. That routing guidance is the missing piece.

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?

Zero parameters, so the baseline is 4. The description correctly implies no inputs are needed ('evaluate ... now'), consistent with the empty schema. Nothing to compensate for.

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?

It names a verb ('Evaluate') and a resource ('schedules and manual overrides') and states the effect ('push any needed allow/block changes to the router'). But it doesn't distinguish itself from the siblings add_schedule, list_schedules, set_access, access_status, which all touch schedules/access. The purpose is understandable but sibling differentiation is weak.

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 explicit when-to-use. The description implies this is the trigger that materializes schedule state, but it never says to call it after add_schedule/remove_schedule, or how it differs from set_access. No alternatives or exclusions are mentioned despite many siblings occupying the same domain.

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=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds a genuinely useful trait not captured anywhere else: the call is slow, roughly 10 seconds, which lets the agent set timeout and user expectations.

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, purpose first, latency warning second. Each sentence carries distinct information with 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?

An output schema exists, so return-value shape needn't be described, and annotations cover the safety profile. Purpose and timing are both addressed; only the distinction from sibling status tools 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 there is nothing for the description to disambiguate; baseline 4 applies. No misleading parameter guidance is present.

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: querying the router for firmware update availability. This is unique among the siblings (device listings, wifi config, schedules, reboot/pause), so an agent can route to it easily, though the description never explicitly contrasts it with any alternative.

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 phrasing ('Ask the router whether a firmware update is available'), which tells the agent the intent but not when to prefer this check over a general status call such as router_status. No when-not conditions or alternatives are given.

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=true, destructiveHint=false, and openWorldHint=false, covering the safety profile fully. The description adds no behavioral context beyond that, e.g. no note on pagination, sort order, retention window, or time range limits, which matter for a historical lookup.

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 dense sentence with the resource and scope front-loaded and zero filler. The parenthetical identifier list is efficient rather than rambling; the only minor flaw is the verbless noun-phrase construction.

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 annotations cover safety. What remains missing is coverage of the 'limit' parameter and any hint of time-window or pagination behavior for a historical query.

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 carry the load; it usefully documents the accepted identifier forms for the required 'device' parameter (MAC, nickname, router name or IP). It says nothing about the optional 'limit' parameter, leaving half the parameters undocumented in both schema and description.

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 resource ('presence sessions for one device') and the exact data returned ('when it joined and left'), which clearly separates it from current-state siblings like known_devices or list_devices. However, it never names or contrasts those siblings, so an agent must infer the distinction itself.

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 when-to-use guidance or reference to alternatives such as known_devices, list_devices, or system_log, which are the obvious competing tools for device information. Usage is only weakly implied by the word 'history'.

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=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description does add a genuine behavioral fact beyond the annotations — the result spans offline devices, not just currently reachable ones — but says nothing about ordering, pagination, or freshness of the registry 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 tight sentences with the scope statement front-loaded before the filter list; nothing redundant. The opening is slightly impressionistic ("what the registry remembers") rather than crisp, which costs a point.

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 shape is handled elsewhere, and the description correctly focuses on scope plus filtering. What remains missing is match behavior for the filters and any result-size/pagination expectation, minor gaps for a simple discovery tool.

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 carry parameter meaning; it does name all three filters (owner, tag, online state), matching the three parameters. However it adds no matching semantics — exact vs substring for tag/owner, or how "online state" maps to the online_only boolean — so compensation is only partial.

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 phrase "everything the registry remembers, online or not" conveys the resource (registered devices, including offline ones) but never names the list/query verb explicitly, so the purpose is implied rather than stated. It hints at a distinction from live-scan siblings like scan_network, but does not name or contrast with list_devices or device_history.

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?

"Filter by owner, tag, or online state" describes capability, not when to choose this tool. There is no condition selecting it over the many siblings (list_devices, scan_network, who_is_new, device_history), no exclusions, and no prerequisites.

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?

The description discloses a genuine write side effect ('records the sighting in the local registry'), which conflicts with the readOnlyHint=true annotation declaring the tool does not modify its environment. Per the rules this contradiction forces a 1, even though the latency warning ('takes a few seconds; the router is slow here') is otherwise useful context.

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 what is returned and followed by the side effect and latency caveat. No filler; every clause carries information an agent would not get from 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?

With zero parameters and an output schema present, the description need not explain return values, and it supplies the two facts an agent most needs: latency and the registry side effect. The only gap is that it never positions itself against the many sibling device-inspection tools.

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 nothing further the description could add about inputs. It instead usefully hints at what the output merges (nicknames, owners, tags, vendor).

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 resource and scope: every device currently attached to the router, merged with nicknames, owners, tags and vendor. The phrase 'right now' implies a live snapshot, which loosely separates it from siblings like device_history and known_devices, but no sibling is named explicitly, so the differentiation is only inferential.

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: an agent can infer this is the tool for the current live device snapshot versus historical or known-device lookups. There is no explicit when-to-use, when-not-to-use, or named alternative such as known_devices or device_history.

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the output includes members and access state, which is useful context beyond the annotations, but it does not discuss the nature of the data (e.g., static snapshot, live state, formatting).

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 compact phrase with no filler. It is front-loaded with the resource, though as a fragment it lacks a clear verb that would make it immediately scannable as an action.

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?

The tool has no parameters and an output schema, so the description need not explain return values. However, it does not say what a 'group' represents, how many groups might be returned, or how this listing relates to sibling tools like access_status, leaving a gap for the agent.

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?

Zero parameters, so there is nothing to document. The baseline for a parameterless tool is 4, and the description does not contradict or undercut that.

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 resource ('device groups') and hints at scope ('with their members and current access state'), but the verb is implicit and the phrase is a noun fragment rather than a complete purpose statement. It does not distinguish itself from siblings like access_status or list_devices, leaving the agent to infer that this is a listing tool.

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 when-to-use guidance, exclusions, or alternatives are provided. The agent is not told whether to call this before set_group_membership or set_access, or how it differs from access_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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description mostly restates what the tool returns (paused devices + daemon status), which the output schema already supplies, so it adds only modest behavioral context about the enforcement daemon.

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 compact sentence with no filler and the scope front-loaded. It is arguably a fragment rather than a full sentence, which slightly weakens the framing but wastes no words.

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 an output schema present, the description need not explain return values, and annotations carry the safety profile. For a zero-parameter read tool it is complete enough, though a brief note on what 'Eclipse Pause' means would help an unfamiliar agent.

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; baseline is 4. The description appropriately does not invent 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?

The description names the resource precisely ('Devices currently held in Eclipse Pause') and adds a second dimension ('whether the enforcement daemon is running'). This clearly separates it from siblings like list_devices, pause_device, and resume_device, though it is a noun phrase rather than a verb-led statement.

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 can infer this is the read-side companion to pause_device/resume_device, but there is no explicit 'use this when...' or exclusion guidance. Nothing is misleading, but nothing directs the choice either.

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=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds one genuinely useful behavioral fact: it computes whether each schedule is currently active, i.e. a derived status beyond raw stored config. It says nothing about ordering, pagination, or empty-result 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?

A single front-loaded clause with no filler; every word carries information (resource + active-status enrichment).

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 shape needs no explanation, and annotations cover the safety profile for a 0-param read tool. The only gap is that it never situates itself against the schedule-mutating siblings.

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?

Zero parameters and 100% schema coverage, so there is nothing for the description to clarify about inputs; the baseline for a no-arg tool 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 resource (schedules) and the returned scope (each with active-right-now status), which is more than a tautology. It does not explicitly contrast with add_schedule/remove_schedule/apply_schedules, but the naming and content make the listing role 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 when-to-use guidance, no mention of the related siblings (add_schedule, remove_schedule, apply_schedules) an agent might need when it actually wants to change scheduling. Usage is only implied by 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 cover the mutation profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=false), and the description adds the crucial scoping fact that changes stay in the local registry and never touch the router. The clear-vs-omit semantics also imply how repeat calls behave. It does not mention permissions or error behavior when the device is unknown.

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 blocks: the scope statement first, then the parameter convention. No filler. Slightly fragmentary ('device: MAC, ...'), but every sentence 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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. Still, for a 5-parameter mutation tool the description omits whether the device must already exist, what tags accept, and what happens on a bad identifier — gaps an agent would want closed.

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 carry parameter meaning. It does explain the `device` parameter's accepted forms (MAC, current nickname, router name or IP) and the null-vs-empty-string convention for the four optional fields, but it adds nothing about tag format, note length, or owner 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 (assign) and resource (nickname, owner, tags, notes in the local registry), and the parenthetical 'nothing changes on the router' cleanly separates it from router-mutating siblings like set_guest_wifi or reboot_router. It does not name a specific sibling to prefer or avoid, so it falls just short of a 5.

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 is for local metadata annotation. The description does explain the important field-editing convention ('pass "" to clear; omit to leave it alone'), which is real guidance, but it gives no when-not-to-use condition or alternative 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?

Goes well beyond the annotations by disclosing that the device stays on wifi and reachable over the LAN, that the pause is recorded, that a root-run eclipse daemon enforces it within seconds, and that it is lifted via resume_device — consistent with destructiveHint=false and idempotentHint=true while adding real operational detail.

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?

Four short sentences, front-loaded with the effect, then mechanism, caveats and the reversal path. No filler, though the mechanism parenthetical and daemon timing detail could be tightened slightly.

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 description covers mechanism, side effects, enforcement latency and reversal. The remaining hole is parameter guidance, particularly accepted target values and the purpose of `reason`, which is left entirely to the schema.

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 carry the parameter burden. It implies the `target` can be a group, owner or device, but never documents target's expected format/identifier, and the optional `reason` parameter is not mentioned at all.

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 (cut off the internet) plus the resource (group, owner or device) and even the mechanism (Eclipse Pause / ARP interception). An agent can distinguish this from sibling tools like set_access or resume_device at a glance.

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 context: it is the immediate cutoff that works on already-connected devices, unlike the MAC block, and it explicitly names resume_device as the way to lift it. It stops short of naming the sibling MAC-block tool itself or stating hard exclusions, but the operative conditions are clear.

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 flag destructiveHint=true, but the description adds the concrete blast radius ('everyone loses internet for about two minutes') and the confirm gate — exactly the operational context annotations cannot express. It does not mention whether this drops all connected clients' sessions or requires admin privileges, keeping it short of a 5. Note the description says confirm is required while the schema marks it optional with default false; this is a schema/description tension, not an annotation contradiction.

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, then impact, then the required input. Nothing is wasted and no sentence restates the tool 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?

An output schema exists, so return values need no explanation, and the description covers action, consequence, and the confirm requirement. What is missing is authorization/prerequisite context (e.g., admin role) and recovery expectations, which matter for a destructive, non-idempotent operation.

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% and the single parameter has no schema-level description, so the description carries the burden — and it does, explaining the confirm flag's semantics ('Requires confirm=true'). No format or default-behavior detail is added beyond that, so a small gap remains.

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 ('Reboot the router') with no ambiguity, and no sibling tool (router_status, reboot-adjacent tools absent) competes for this action. An agent can select it immediately.

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: it is clearly the disruptive recovery action, but the description never says when to prefer it (e.g., after check_firmware, router_status, or repeated disconnects). Since no sibling offers an alternative reboot path, the omission is tolerable, but no explicit when/when-not guidance is given.

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?

The description explicitly says it 'Delete[s] a schedule', but the annotation declares destructiveHint=false, which per MCP means the tool performs only additive updates. An agent reading both cannot tell whether data is actually destroyed. The note about devices being released at the next apply is useful timing context but does not resolve the destructive/non-destructive conflict.

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 action and free of filler. The second sentence carries genuinely useful timing information 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?

An output schema exists, so return values need not be explained, and the description covers the action plus its downstream effect. However, it omits permission/auth requirements and leaves the destructive semantics unresolved.

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 is a single parameter with 0% schema description coverage. 'By id' implies the argument is the schedule identifier, but no format, validity range, or failure behavior (e.g., unknown id) is given, so compensation for the schema gap is minimal.

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 ('Delete'), a specific resource ('a schedule'), and the addressing mechanism ('by id'). It is cleanly separable from siblings such as add_schedule, list_schedules, and apply_schedules.

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 — removing a schedule you no longer want. It never states when to prefer this over add_schedule/list_schedules, nor how it relates to apply_schedules, which is the step that actually releases the devices.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the effect scope (targeted vs all devices) but says nothing about required permissions, who may resume, 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 with no filler; the scope and the all_devices override are stated efficiently.

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 annotations cover safety; the description is nearly sufficient for this two-parameter toggle. The remaining gap is the target string format, which no structured field documents.

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 carry the load, and it does explain that 'target' names a group, owner, or device while all_devices=true applies to everyone. It does not clarify the accepted target format (name vs. ID) or the behavior of the empty default.

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 action ('Lift an Eclipse Pause') on a specific resource, and the scope (group, owner, device, or everyone). An agent can distinguish it from the inverse sibling pause_device and from list_paused without opening any 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?

Usage is only implied: the agent infers this is the inverse of pause_device and is used to undo a pause. No explicit when-to-use, when-not-to-use, or named alternatives are given.

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?

The annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false. The description adds no behavioral context such as authentication needs, rate limits, or pagination; it only lists return fields that the output schema already covers.

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 noun phrase listing fields, with no wasted words. However, it is a fragment rather than a front-loaded purpose statement, and the list format is less helpful than a sentence explaining what the tool does.

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?

Because an output schema exists, the description need not enumerate return values, yet it does so instead of adding purpose or usage context. It is minimally adequate for a simple read-only tool whose annotations cover safety, but it lacks guidance for selecting among many sibling tools.

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 the baseline is 4 per the scoring rules. The description has no parameter information to add, and none is needed.

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 enumerates data points such as 'Router model, firmware, uptime, CPU and memory' but never states a verb or purpose sentence like 'retrieve router status.' It implicitly distinguishes some data from siblings through the field list, but provides no explicit sibling differentiation.

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 is given for when to use router_status instead of siblings like wifi_info, traffic_stats, or check_firmware. There are no prerequisites, exclusions, or alternative conditions mentioned.

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 cover the safety profile (readOnlyHint=true, openWorldHint=false, destructiveHint=false), which fully answers whether it's safe and whether it touches the outside world. The description adds the registry-refresh side effect and the three-way outcome categorization, but doesn't mention scope (all devices? one network?) or any rate limits, and doesn't disclose whether the refresh is synchronous. Some value added but not rich.

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?

One compact sentence that front-loads the action ('Refresh the registry') and then adds the outcome categories. No 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?

An output schema exists, so the description needn't explain the return structure, and it correctly does not. The description is complete enough for a zero-parameter scan given annotations cover safety and output schema covers results, though it doesn't clarify what 'registry' means or the scope of the scan.

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?

Zero parameters, so the baseline is 4 per the rubric. The schema has no fields to misinterpret and the description correctly implies the tool takes 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 (Refresh) and resource (the registry), plus the side effect of reporting changes (new devices, returned, left). Clear enough to distinguish from read-only siblings like known_devices or list_devices, though it doesn't name an alternative.

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 explicit when-to-use vs. alternatives, but a reasonable agent can infer that this is the tool to invoke when you want to discover changes since last scan, as opposed to simply listing known devices. Implied usage only.

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 write, idempotent, non-destructive, so the bar is lower; the description nonetheless adds real behavior: blocking relies on the router's Access Control and auto-enables it on first use, and a manual change persists only until the next scheduled change (or until flipped back). That timing/precedence detail is exactly the kind of context an agent can't get from structured fields.

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, front-loaded with the core action and then the two non-obvious behavioral rules. No filler, though the embedded quote style (e.g. "kids") is slightly noisy.

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 annotations carry the safety profile. Combined with the description's coverage of target forms and change duration, an agent has enough to invoke it correctly; the undocumented `reason` parameter is the main residual 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?

Schema description coverage is 0%, so the description must carry parameter meaning. It explains the accepted target forms (group name, owner name, single device) with examples, but says nothing about the `reason` parameter and only implicitly covers `enabled`. Partial compensation for the coverage gap.

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 ("Turn internet access on or off") and enumerates the three valid target kinds (group, owner, single device) with concrete examples. It does not, however, distinguish itself from close siblings like pause_device or resume_device, which appear to touch the same capability.

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 target examples and the duration rule, but there is no explicit when-to-use-this-vs-alternative guidance, and the overlap with pause_device/resume_device is left unresolved. An agent cannot tell from the text which of these to pick.

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 the safety profile (readOnly=false, idempotent=true, destructive=false), so the bar is lower. The description nonetheless adds a genuinely useful behavioral fact not in any structured field: groups are auto-created on first use, meaning the call has an implicit upsert side effect on the group itself. It stops short of describing effects on existing members 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?

Two short sentences, zero filler, front-loaded with the primary action before the side-effect note. 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?

An output schema exists, so return values need not be explained, and annotations cover safety and idempotency. Combined with the description's coverage of add/remove semantics and auto-group creation, an agent has what it needs. Missing only edge-case behavior, such as removing a device that is not a member.

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 carry parameter meaning, and it does for the parameter that matters: member=true adds, member=false removes. The device and group parameters are only implied by the sentence structure rather than defined, so it does not fully compensate for the zero coverage.

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 verb+resource pair ('Add/remove a device to/from a group') and immediately resolves the only ambiguity in the name by mapping member=true to add and member=false to remove. No sibling tool performs group membership mutation (list_groups only reads), so an agent can select it without inspecting schemas.

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 through the boolean semantics: the agent learns which value to pass for adding vs removing. However, there is no explicit when-to-use framing, no prerequisites, and no mention of an alternative path (e.g. list_groups to verify membership first). Adequate but leaves inference on the agent.

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 the full safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=false), and the description is consistent with them. Beyond stating the mutation, it adds nothing behavioral – no mention of client disconnection, radio restart, or scope of effect – so with annotations carrying the load this is a bare-minimum 3.

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 compact sentences with zero filler; the core action is front-loaded and the parameter detail follows. Nothing could be removed without losing 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 values need not be explained, and the description covers the action plus the one non-obvious parameter. The remaining gap is contextual usage – no prerequisites or effect disclosure – but for a two-parameter toggle this is close to sufficient.

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 carry the burden, and it does for the ambiguous parameter by enumerating the valid band values (2.4, 5, or both), which the schema does not. The 'enabled' boolean is self-evident and needs no elaboration, though the description does not restate that it is required.

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 verb ('turn on or off') and resource ('guest wifi network'), so the agent immediately knows what the tool mutates. It does not, however, differentiate itself from other write-oriented siblings such as set_access or apply_schedules, so it stays short of a 5.

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 statement of when to use this tool, when not to, or which sibling to pick instead – for example, no guidance distinguishing guest-network toggling from set_access or pause_device. Usage is only inferable from the name, which is the definition of no explicit guidance.

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavior: results are returned newest-first and span three distinct log categories. It does not disclose retention window, max entries available, or pagination 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?

Two short sentences with the returned content and ordering front-loaded, followed by the one non-obvious filter rule. Zero filler; every clause 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?

An output schema exists, so return-value structure need not be restated. Safety is covered by annotations, and the description covers content, ordering, and filtering. The remaining gap is the limit parameter's behavior (default and ceiling), which is left entirely to the schema.

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. It does explain category meaningfully (substring match, with concrete examples like 'DHCP' and 'Access Control'), but says nothing about limit, which silently defaults to 50 and bounds the result set size. Partial compensation for two undocumented 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?

Names the specific resource (router log entries) and its ordering (newest first), plus the entry types returned (DHCP leases, Access Control decisions, attack warnings). It's a noun phrase rather than an explicit verb, but the retrieval purpose is unambiguous. No sibling tool deals with logs, so it is inherently distinguished from the rest of the toolset.

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 guidance on when to reach for this tool versus the other diagnostics-oriented siblings such as router_status, traffic_stats, or who_is_new. The only usage hint is how the category filter behaves, which is invocation mechanics rather than selection guidance.

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds a genuinely non-obvious behavioral trait beyond that: values are zero unless the traffic meter is enabled, which prevents an agent from misreading zeros as real traffic. It omits any retention, refresh, or granularity detail, so it stops at 4.

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 resource and time coverage front-loaded and the caveat placed second. 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?

With no parameters and an output schema present, the description need not explain return values, and the 'zero unless enabled' caveat covers the main interpretive risk. It is complete enough to call correctly, though a note on whether the meter must be toggled elsewhere would close the last 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 per the rubric the baseline is 4. The schema's empty properties object means there is nothing further to disambiguate, and the enumerated time ranges describe the fixed output shape rather than configurable 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 resource (traffic meter totals) and enumerates the exact time buckets returned (today, yesterday, week, month), so an agent knows precisely what data this yields. No sibling reports traffic data, but the description never explicitly rules alternatives in or out, keeping it just short of a 5.

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 explicit when-to-use/when-not statement or named alternative. The clause 'Zero unless the meter is enabled' implicitly tells the agent when this tool is worth calling and when its output will be meaningless, which is a partial but real usage cue.

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 this a safe, local, non-destructive read. The description adds a genuinely useful behavioral trait beyond that: 'Runs a scan first', warning that the call triggers an active network scan rather than returning cached data. It stops short of saying how long that scan takes or whether it blocks.

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 compact sentences, front-loaded with what qualifies as 'new' and followed by the side effect. No 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?

With an output schema present, return values need no explanation, and the description covers the filter semantics and the scan side effect. The only gap is the absence of any routing guidance among the many device-listing siblings.

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 carries the burden — and it does, spelling out the accepted formats ('7d', '24h', '30m', or an ISO date) for the only parameter. It does not restate the 7d default, which the schema supplies.

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 resource and filter: devices first seen after a given time window. An agent can distinguish this from siblings like known_devices or list_devices, though it never names an alternative 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?

Usage is implied by the 'first seen' framing — you use it to find newly joined devices — but there is no explicit when-to-use statement or routing to alternatives such as known_devices or device_history.

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds scoping context (both 2.4 and 5 GHz bands, guest network state included) but says nothing about freshness, permissions, or whether it reflects live vs. cached state.

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 tight sentence with no filler, and the scope (both bands) is stated up front. It loses a point only because leading with a bare noun phrase rather than an action statement makes it slightly less immediately actionable.

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 the description needn't explain return values — and in fact its field enumeration partly duplicates that schema. For a zero-param read tool the remaining gap is sibling disambiguation against router_status, which is not addressed.

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 convey — baseline 4 applies. The description's band references are not parameters but rather describe fixed coverage, which is harmless.

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 enumerates the data returned (SSIDs, channels, security mode, guest network state) and the bands covered, so the resource is identifiable, but it never states a verb or that this is a read/retrieval operation. It also fails to distinguish itself from the sibling router_status, which an agent could easily confuse with Wi-Fi configuration data.

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 when-to-use guidance at all — no mention of when to call wifi_info versus router_status, scan_network, or set_guest_wifi (the obvious mutation counterpart for the guest-network state it reports). The agent is left to infer selection from the field list alone.

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