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

With no annotations, the description carries full behavioral burden and falls well short. It does not say whether the check is read-only, what domains are tested and how many, which DoH endpoint is used, whether it makes external network calls (relevant for sandboxed/offline agents), or what a 'Finding' object contains. The single declared behavior -- mismatch produces a Finding -- is the only disclosure.

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?

It is short and front-loads the mechanism, but 'Killer check' is filler that consumes the opening position, and 'DoH' is never expanded. The compression costs more clarity than it saves tokens.

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

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

No output schema and no annotations means the description is the only documentation, and it omits the input universe (which domains), the execution model (external DoH lookups), and the shape of the Finding result. For a network diagnostic that may fail in restricted environments, that is a substantial 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?

Zero parameters, so the schema-driven baseline of 4 applies; there is nothing for the description to clarify beyond confirming the tool is parameterless and fully automatic.

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 does convey the core mechanic: compare answers from the system resolver against a trusted DoH resolver and emit a Finding on mismatch. However, 'Killer check' is unexplained jargon and neither the set of 'known-good domains' nor the term 'Finding' is defined, so the agent must guess at scope and output. It is distinguishable from dns.lookup in spirit but not stated in terms an agent can act on confidently.

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

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

There is no indication of when to run this versus dns.lookup, dns.propagation, or dns.resolvers, all of which touch similar territory. No prerequisites, no exclusions, no note about whether this requires outbound DoH access.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a network DNS query and mentions a custom nameserver, but it omits timeout behavior, failure modes, response shape, and whether it contacts a remote resolver. This is minimal disclosure for an unannotated network 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?

The description is a single concise fragment with no wasted words and the key record-type list is front-loaded. However, its fragmentary structure and extreme brevity leave important information unstated, making it concise at the expense of usefulness.

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?

There is no output schema and no annotations, and the description does not explain result format, errors, or how record type selection affects the response. For a DNS lookup tool with eight record types and a nameserver override, the definition is substantially incomplete.

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 for all three parameters. It lists the record types and nameserver override, but does not explain the required name parameter, the default record value of A, or the fact that nameserver must be an IPv4/IPv6 address.

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 operation: a DNS lookup for several record types with an optional nameserver override. It is clear enough to identify the tool's function, but it does not distinguish it from siblings such as dns.reverse or dns.propagation, especially because PTR is also listed as a record type here.

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

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

The description gives no when-to-use guidance, no prerequisites, and no comparison to alternatives like dns.reverse, dns.resolvers, or dns.propagation. The only contextual hint is the optional nameserver override, which is too thin to guide tool selection.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only query and mentions a 'diff table' output, but does not describe resolver selection, DoH behavior, permissions, latency, or what the diff actually compares.

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?

It is short and front-loaded, but the telegraphic phrasing 'Same record' lacks an antecedent and the sentence fragment does not provide clear structure. It is concise to the point of being cryptic.

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?

Given no annotations, no output schema, and zero schema description coverage, the description is too sparse. It does not explain the two parameters, which resolvers are used, how DoH is involved, or what the diff table contains.

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 description says nothing about the required 'name' parameter or the optional 'record' parameter. 'Same record' hints at a record but does not explain the parameters, enum values, or 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 fragment conveys that it queries the same DNS record at multiple trusted resolvers and DoH endpoints and produces a diff table. However, it omits an explicit verb like 'check propagation' and does not distinguish itself from siblings such as dns.lookup, dns.resolvers, or dns.hijackcheck.

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 use this tool versus alternatives, no exclusions, and no mention of prerequisites. The agent must infer that this is for propagation comparison rather than ordinary lookup or hijack detection.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not say whether this reads local configuration files, which platform sources it consults, or whether any state is touched – only the 'actual OS' angle hints that it is a local read rather than a remote query.

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 short fragment with zero filler, though it lacks a leading verb and is a sentence fragment rather than a structured statement of purpose.

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

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

There is no output schema and no annotations, and the description never indicates what comes back – a list of resolver IPs, protocol details (DoH/DoT), or interface associations are all left unknown. For a zero-param diagnostic tool with no structured return contract, that is a meaningful 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. The description correctly implies the call is argument-free.

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 identifies the resource (DNS resolvers) and scopes it to those the OS actually uses, which does implicitly distinguish it from name-resolution siblings like dns.lookup or dns.propagation. But it is a noun phrase with no verb, so it never states that it returns/reads configuration rather than modifying it.

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 guidance on when to reach for this versus dns.lookup, dns.propagation, or lan.gateway, and no prerequisites or exclusions. The agent must infer the use case entirely from the name.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it delivers almost nothing: it hints that PTR names are returned but says nothing about which resolver is queried, what happens when no PTR record exists, or whether multiple names can come back.

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?

It is only four words, which is under-specification rather than conciseness. There is no front-loaded verb and no structure to build an invocation around.

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 annotations and no output schema, the description is the only source of behavioral context and it supplies essentially none. A zero-parameter tool is simple, but the agent still cannot tell how the target IP is determined or what the response looks like.

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 schema declares zero parameters, which would normally warrant a baseline 4. However, the description's "for an IP" falsely implies an IP argument exists, contradicting the empty schema and risking an agent supplying an unsupported 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?

"PTR names for an IP" identifies reverse-DNS PTR resolution as the resource, which does distinguish it from dns.lookup in principle. But it is a noun fragment with no verb, and the phrase "for an IP" implies an input the tool cannot accept, so the agent cannot fully form the call.

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 statement, no exclusion, and no mention of the obvious alternative dns.lookup for forward resolution. The reverse-vs-forward distinction is only inferable from the word PTR, which requires DNS expertise.

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 behavioral burden. It discloses that output is parsed and stale entries are filtered, which is useful context, but it does not clarify read-only safety, permissions, or the exact shape of returned 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?

The description is a single, front-loaded phrase with zero wasted words. It communicates the core functionality immediately without unnecessary elaboration.

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 simple, parameterless read tool with no annotations or output schema, the description is adequate but incomplete. It states what is returned but not the structure (e.g., IP–MAC pairs) or any operational prerequisites, which would help an agent use the result confidently.

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 of 4 applies. The description does not need to explain parameter semantics, and schema coverage is trivially 100%.

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

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

The description names a specific resource (ARP/neighbor cache) and indicates it is parsed with stale entries filtered. It is clearly distinct from siblings like lan.devices or lan.interfaces, though it lacks an explicit verb and direct sibling comparison.

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 use this tool versus alternatives, no prerequisites, and no exclusions. The specific resource implies usage, but the description provides no explicit context for selection.

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

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

With no annotations, the description carries the full burden, and it does disclose the method: ARP union RFC1918 filtering and enrichment via OUI and PTR. However, it does not state that the operation is read-only, whether it scans or only reads local tables, expected runtime, or any rate-limit or permission 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?

The definition is a single compact sentence with no wasted words, and it front-loads the core operation before the enrichment details. The compactness is appropriate for a zero-parameter inventory tool.

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 tool, the description explains the data sources and enrichment, but with no output schema or annotations it does not describe the return format, whether results are sorted, or how RFC1918 filtering affects scope. It is adequate but leaves several operationally useful details 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?

The tool has zero parameters, so parameter semantics are not a meaningful differentiator. The empty schema is fully described and the description does not need to compensate for parameter documentation.

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 concrete inventory operation over LAN devices and specifies the data sources: ARP union RFC1918 filtering, plus OUI vendor and PTR hostname enrichment. It is clear enough to distinguish this from a bare hostname or ARP lookup, though it does not explicitly name sibling tools such as lan.arp or lan.newdevices.

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, no exclusions, and no mention of alternatives like lan.arp, lan.sweep, or lan.newdevices. The only implied usage is that this produces a device inventory, leaving the agent to infer the selection criteria.

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 provided, the description carries the full burden. It implies a passive read but says nothing about whether the call is local-only, what happens when no default gateway exists, or whether results are cached/live — meaningful gaps for a network probe 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?

Seven words with no filler, but the '+' notation reads like a field list rather than a sentence. It is terse to the point of under-specification, so brevity comes at the cost of clarity.

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 tool with no output schema, listing the returned fields (gateway, interface, subnet CIDR) is the right instinct and partially compensates for the missing output schema. It still omits behavioral context such as failure modes and whether the data is local-scope only.

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 schema declares zero parameters, so there is nothing for the description to disambiguate. The baseline of 4 applies; the entry is correctly parameterless.

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 fragment 'Default gateway + interface + local subnet CIDR' names the three data points it surfaces, which implicitly separates it from siblings like lan.interfaces and lan.arp. However, there is no verb or return framing ('retrieves', 'returns'), so the agent must infer that this is a read of network configuration rather than a setter or a diagnostic.

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, when-not-to-use, or alternative guidance is given. An agent cannot tell from this description whether to call lan.gateway or lan.interfaces for interface data, nor whether it needs to be on the local network.

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

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

No annotations are provided, so the description carries the full burden, and it discloses only the resolution methods. It says nothing about whether NetBIOS actively probes the target host, latency/timeout behavior, how failures or partial results are reported, or whether the returned list can be empty.

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 short, front-loaded sentence with no filler. It is arguably under-specified rather than verbose, but nothing in it is wasted.

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 lookup with no output schema and no annotations, the description should say what comes back and how misses are surfaced. It hints at the return content ('all known names') but leaves the response shape and failure behavior for the agent to discover.

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%, but there is only one parameter and the schema's anyOf already constrains it to IPv4/IPv6 formats. The description confirms the parameter is an IP, but does not say whether IPv6 targets yield anything beyond PTR or whether private/LAN addresses are expected.

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 ('all known names for an IP') and the two mechanisms used (PTR, NetBIOS), which is more specific than the tool name alone. It does not distinguish itself from the sibling dns.reverse, which also performs PTR resolution, so an agent cannot tell them apart from the description.

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 call this versus dns.reverse or dns.lookup, and no prerequisites or exclusions are given. The only usage hint is implicit in the mention of NetBIOS being Windows-oriented ('win').

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about read-only safety, side effects, or whether empty arrays are normal (e.g. no ipv6). Local enumeration is implicitly a safe read, but the definition never states it.

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

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

A single compact statement with no filler, front-loading the return type. It reads as a schema fragment rather than prose, which is efficient but slightly cryptic for an agent that has no other context.

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

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

No output schema exists, and the description partially compensates by listing the result fields (name, mac, ipv4[], ipv6[], type). The remaining gap is scope: whether these are the local host's adapters or LAN-wide data, which is exactly the ambiguity that matters given the sibling set.

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 of 4 applies. The description instead documents the Nic[] record shape, which is useful but is output information rather than parameter meaning.

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

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

The description names a specific resource (network interfaces) and enumerates the returned fields, but uses no verb and never says whose interfaces these are – local host NICs versus something discovered on the LAN. With siblings like lan.devices, lan.arp and lan.gateway, an agent could reasonably misroute to this 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?

There is no when-to-use guidance, no exclusion rules, and no reference to any of the 30 sibling tools. The agent must infer from the field list alone whether this is the right tool for enumerating local adapters.

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 behavioral burden. It usefully discloses the first-run baseline side effect and the return shape, but it does not clarify whether later runs update the snapshot, whether the tool is read-only after baseline creation, or what permissions/rate behavior apply.

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 extremely compact and front-loads the core diff operation, with the first-run behavior following immediately. The arrow notation and terse phrasing are slightly cryptic, but no sentence is wasted.

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, stateful diff tool with no output schema and no annotations, the description covers the essential purpose and return categories. However, it leaves ambiguity around snapshot lifecycle and exact Finding[] structure, which would matter for repeated or automated use.

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 there is nothing for the description to disambiguate. The baseline score for zero-parameter tools is 4, and the description does not introduce confusion.

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 operation: diff live devices against the latest snapshot, and names the return type and the two finding categories. It clearly distinguishes itself from siblings like lan.devices (list devices) and lan.snapshot (capture 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?

It gives clear context for when to use it: comparing live devices to the latest snapshot, with a note that the first run saves a baseline. It does not explicitly name alternatives or exclusions, such as when to use lan.snapshot instead, which keeps it below a 5.

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; it does disclose that save captures the current lan.devices list and that snapshots are dated, which tells the agent this mode mutates stored state while list is a read. It omits key traits such as whether a same-day save overwrites, where snapshots live, and any retention limit.

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 the write action front-loaded and the secondary read action trailing. No filler, and the two modes are separated by a clear semicolon.

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 tool with no output schema, the description covers the essentials, but it leaves real gaps: what a list result looks like, where snapshots are stored, and what happens on repeated saves. An agent can call it correctly but cannot predict the outcome of list or repeated saves.

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%, but the enum values are self-describing and the description maps each to concrete behavior (save = snapshot current devices, list = enumerate snapshots), which is more than the bare enum provides. It doesn't restate the schema's default of 'list' for an omitted mode.

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

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

The description gives a specific verb and resource: it saves the current lan.devices list into a dated snapshot, or lists existing snapshots. It ties the write behavior to the lan.devices sibling, making the data source unambiguous, but it doesn't distinguish itself from other lan.* siblings beyond that reference.

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 two clauses imply which mode to pick (save vs list), but there is no explicit guidance on when to snapshot versus just calling lan.devices, and no mention that omitting mode defaults to list. Usage is inferable rather than stated.

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 two real behavioral constraints: private-range-only targeting and a 1024-host cap. It says nothing about duration, rate limiting, concurrency, timeout, or whether the scan blocks — relevant for a sweep that can touch 256+ hosts.

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 front-loaded line with no filler and the key constraint (subnet range) placed prominently. The arrow shorthand is compact, though it compresses away detail that would have been useful.

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?

A network sweep is an inherently slow, side-effecting operation with no annotations and no output schema to lean on, yet the description omits runtime expectations, behavior on unresponsive hosts, and result contents beyond 'live set'. It is also internally inconsistent with the schema's /24–/30 restriction versus the stated 1024-host cap.

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 single 'subnet' parameter is undocumented in the schema beyond a regex. The description adds the RFC1918 requirement, but the cap of 1024 hosts conflicts with the schema pattern that permits only /24–/30, and required-ness and accepted formats are never spelled out.

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 (ping-probe) and resource (RFC1918 subnet) plus the return shape (live set), so an agent knows exactly what it does. It never distinguishes itself from close siblings like net.ping or lan.devices, which do related host-liveness work.

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

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

No indication of when to prefer this over net.ping (single host), lan.devices (enumerate known devices), or net.portscan. The RFC1918 constraint is a scoping rule, not usage guidance, and there is no statement of prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the operation is mutating and follows a dry-run/token confirmation flow, but it omits permission scope, network reach, failure behavior, and error semantics.

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 two compact sentences, front-loaded with the operation and followed by the mutation workflow. Every sentence adds relevant information with 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?

For a simple three-parameter network tool with no annotations or output schema, the description covers the core purpose and confirmation workflow. It remains thin on parameter semantics and operating context, leaving clear gaps.

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

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

Schema description coverage is 0%, yet the description only indirectly explains confirmToken and does not describe mac (required, format) or port (default, target). It adds minimal meaning for two of the three 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 a specific action and mechanism: Wake-on-LAN magic packet over UDP broadcast. It is clear what the tool does, though it does not explicitly distinguish itself from the surrounding lan.* diagnostic siblings.

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

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

The dry-run/confirmToken sequence explains how to execute the operation, but there is no explicit guidance on when to use this tool versus alternatives, nor any stated prerequisites or exclusions. Usage is implied through the WoL purpose and confirmation workflow.

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 it does disclose real behavioral facts: the external binary dependency, a config gate that can make it unavailable, and that it only accepts RFC1918 targets. It says nothing about runtime cost/duration, what happens on non-private hosts, error behavior when nmap is missing, or what the scan yields — meaningful gaps for an active scanning 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?

Three short sentences, front-loaded with the capability and scope, then the hard prerequisites, then the rationale. No filler and nothing repeated 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?

For a no-annotation, no-output-schema mutation-class tool with 0% parameter coverage, the description should explain ports/topPorts semantics and roughly what the scan returns. It covers the gating well but leaves the agent unable to choose parameters or anticipate output.

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?

Three parameters with 0% schema description coverage, and the description mentions none of them by name. "LAN RFC1918 targets" hints at the host constraint, but ports and topPorts — the parameters that actually determine scan behavior and duration — get no explanation beyond bare regex/range constraints in the schema.

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

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

States a specific verb+resource (nmap deep scan) and constrains the target scope to LAN RFC1918 addresses, which meaningfully separates it from public-target siblings like net.portcheck/net.publicip. It never names the lighter-weight sibling (net.portscan, lan.sweep) it is the heavyweight alternative to, so the differentiation is implied rather than stated.

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

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

"Optional" and "opt-in by design" plus the two prerequisites (nmap on PATH, nmap.enabled=true) tell the agent this is gated and may be unavailable. However, there is no explicit when-to-use/when-not guidance and no named alternative among the many scan siblings, so selection between net.deepscan and net.portscan is left 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?

No annotations exist, so the description carries the full disclosure burden, yet it says nothing about whether this is a local read-only probe, whether it requires credentials or elevated privileges, or whether "config caps" exposes sensitive configuration. For a zero-parameter introspection call the risk is low, but the behavioral surface is essentially undocumented.

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?

Eight words, front-loaded, with no filler or repetition. The terseness borders on under-specification, but nothing in it is wasted.

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 is the only source of return-value information, and it names output categories vaguely ("capability matrix", "config caps") without saying what those contain or in what shape. It is minimally adequate for a no-parameter probe but leaves the agent guessing about what it will actually receive.

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 input schema has zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. It gains no extra credit since it adds no meaning beyond the empty schema.

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

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

The description is a bare noun list of returned data ("Server version, platform, capability matrix, config caps") rather than a verb+resource statement, so an agent must infer that this tool reports the health/capability profile of the local server or agent host. It conveys the topic but does not distinguish it from the sibling wifi.health, which likely has an overlapping remit.

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 call this versus alternatives, no prerequisites, and no indication of cost. With 32 sibling tools including wifi.health, sec.exposure and net.publicip, the agent is given no basis for choosing this one.

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

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

With no annotations the description carries the full burden. It does disclose the return contents (timing breakdown, headers, size) and signals a safety posture via 'LAN-safe', but leaves redirect handling, error/timeout behavior, and what 'LAN-safe' actually means undefined.

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 line with the payload (methods, outputs) front-loaded and zero filler. The telegraphic fragment style trades some readability for compactness, but no sentence is wasted.

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 3-parameter, annotation-free tool with no output schema, the description is too thin: it does not explain timeout effects, failure modes, or whether redirects are followed, all of which an agent needs before choosing it over net.ping or net.health.

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 schema documents only types, defaults and enum values. The description echoes the GET/HEAD method values but says nothing about url format expectations or the 1s-30s timeoutMs range and what happens when it elapses.

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 the resource and method (HTTP GET/HEAD) and enumerates the results it returns (timing split dns/connect/ttfb/total, status, headers, size), which lets an agent separate it from ICMP/TCP siblings like net.ping or net.portcheck. It never names a sibling explicitly, so differentiation is inferential rather than stated.

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

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

There is no when-to-use or when-not-to-use guidance and no pointer to an alternative such as net.ssl, net.health or sec.exposure. The only contextual hint is the trailing phrase 'LAN-safe', which gestures at suitable environments without explaining the criterion.

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. It usefully discloses the TCP-connect fallback and that the fallback is reported honestly, but it does not mention permission requirements for raw ICMP, rate limits, timeout behavior, or what the response fields contain beyond the listed stats.

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?

It is a single front-loaded sentence with no filler, but the extreme terseness leaves terms like 'mdev' and the fallback mechanism unexplained. It is concise, though perhaps too compressed for a three-parameter tool.

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 network probe with no annotations, no output schema, and zero parameter descriptions, the definition is too thin. It should at least clarify the host/count/timeout behavior and what the honest fallback reporting looks like.

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

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

Schema description coverage is 0% for three parameters, and the description says nothing about host, count, or timeoutMs. An agent must infer all parameter meaning from names and schema constraints alone, which the description does not supplement.

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 mechanism and resource: ICMP ping, with min/avg/max/mdev statistics, plus a TCP-connect fallback. This distinguishes it in spirit from siblings like net.trace and net.health, but it does not explicitly name or contrast any sibling 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?

There is no guidance on when to use this tool versus net.health, net.trace, net.portcheck, or net.httpcheck. The only implied use is a basic reachability/latency check, but no conditions, exclusions, or alternatives are stated.

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 behavioral burden. It usefully discloses that this is a single TCP connect and that the result includes open/closed state and latency, but it omits timeout behavior, IPv4/IPv6 handling, and whether the check performs only a TCP handshake or any application-layer probe.

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 extremely concise and front-loads the core operation and output. It avoids waste, though its terseness contributes to missing guidance elsewhere.

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 tool with no annotations, no output schema, and 0% schema description coverage, the description is too sparse. It gives the basic operation and result shape but leaves parameter semantics, timeout behavior, and usage distinctions incomplete for an agent to invoke it confidently.

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 neither host nor port has documented meaning in the schema. The description implies connecting to a host and TCP port but adds no detail about hostname/IP format, port range, or what values are valid beyond the schema's raw constraints.

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 operation: a single TCP connect returning open/closed status plus latency. The word 'Single' distinguishes it from the sibling net.portscan, though it does not explicitly name that 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?

There is no explicit guidance on when to use this tool versus net.ping, net.portscan, net.httpcheck, or net.ssl. The word 'Single' implies one-port checking, but no conditions, exclusions, or alternatives are stated.

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 behavioral burden. It usefully discloses that this is a bounded TCP connect scan, defaults to top common ports, and caps scanning at 256 ports, but it omits permissions, intrusive side effects, timing, rate limits, and return 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?

The description is a single front-loaded sentence with little wasted wording. It is perhaps too terse for the tool's risk profile, but the conciseness itself is effective.

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?

Given no annotations, no output schema, and 0% parameter description coverage, the description is not complete enough. An agent would still lack return-value expectations, permission/security context, and clear operational boundaries for a network scanning 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 compensate for both parameters. It partially explains the ports behavior via default top common ports and a 256 cap, though the cap duplicates the schema's maxItems, and it leaves the required host parameter and port-list format essentially undocumented.

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 a TCP connect port scan and scopes it with default common ports and a 256-port cap. It is specific about the resource and method, but it does not distinguish this tool from nearby siblings such as net.portcheck or net.deepscan.

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 guidance on when to use this tool versus net.portcheck, net.deepscan, or other network tools. The description implies a port-scanning use case but gives no exclusions, prerequisites, or alternative-routing advice.

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

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

No annotations exist, so the description carries the full burden; it usefully discloses that this performs an external network call, which is real behavioral context. It omits failure behavior, privacy/rate considerations, and the exact response shape beyond the parenthetical.

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 fragments with the core fact front-loaded and nothing wasted. The '+ASN/org' shorthand is slightly cryptic but readable in context.

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

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

For a zero-parameter, no-output-schema lookup, the description says what it returns and flags the external-call nature. Only error/empty-result behavior is left unspecified.

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; nothing in the description needs to compensate for undocumented inputs.

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

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

States a specific verb-resource outcome: returns the public IPv4 address plus ASN/org. That clearly separates it from siblings like dns.lookup or lan.interfaces, though it never names 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?

'Explicitly user-requested external call' implies a gating condition (only run when the user asks, since it goes outside the machine), but there is no explicit when/when-not or pointer to a related local-IP sibling like lan.interfaces.

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

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

No annotations exist, so the description carries the full burden; it does disclose the returned fields, which is genuinely useful with no output schema present. However, it says nothing about live network connection behavior, failure modes for expired or self-signed certs, or how the 'grade' is computed.

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 clause with the resource type front-loaded and no filler. It is efficient, though the fragment style leaves little room for the missing guidance.

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?

Listing the returned fields partly compensates for the absent output schema, but with zero annotation coverage and zero parameter descriptions, an agent still lacks enough to invoke it confidently against the wrong port or interpret failures.

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% across three parameters: host, port, and timeoutMs are all undocumented in the schema. The description implies host/port via 'TLS cert inspection' but never explains the port default of 443 or what timeoutMs controls, so it only partially compensates.

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 a specific resource and operation ('TLS cert inspection') and enumerates what the result contains (subject, SANs, issuer, expiry, daysLeft, grade). It is distinguishable from siblings like net.httpcheck or net.portcheck, though it is a noun-phrase fragment rather than a stated verb.

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 call this versus net.httpcheck, net.portcheck, or net.health, and no mention of prerequisites such as the target needing to serve TLS on the given port. The agent must infer all invocation context.

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 of behavioral disclosure. It reveals the hop-list output fields, but says nothing about required privileges, timeout behavior, blocking risks, protocol used, or what happens when a hop fails to respond.

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 single fragment is concise but severely under-specified for a tool with three parameters, no annotations, and no output schema. Brevity here comes at the cost of necessary context rather than efficient communication.

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 definition is incomplete given the lack of annotations, output schema, and parameter descriptions. It partially describes return fields but omits host format expectations, default and maximum behavior for maxHops and timeoutMs, and operational caveats an agent would need to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented parameters. It mentions only output fields (ttl, ip, latency) and adds no meaning for 'host', 'maxHops', or 'timeoutMs', leaving all three parameters without descriptive semantics.

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 'Traceroute hop list' clearly identifies the operation and the resource it returns, and '(ttl, ip, latency)' specifies the output fields. It does not explicitly differentiate itself from siblings such as net.ping or net.deepscan, but the purpose is still readily understandable.

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

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

The description provides no guidance on when to use this tool versus alternatives like net.ping, net.portcheck, or net.deepscan. There are no exclusions, prerequisites, or contextual cues to help an agent select it correctly.

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 it discloses almost nothing: it does not say whether the call is read-only (implied but unstated), whether elevated privileges are required to resolve PID/process ownership (a real constraint for socket-to-process mapping), or anything about output shape or snapshot semantics.

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?

It is a single sentence with no padding, which is good, but the compactness comes from omission rather than discipline. The most decision-relevant fact, contrast with sec.listening, is missing entirely.

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-param tool with no annotations and no output schema, the description must supply the missing context itself. It does not explain the privilege requirement, the returned fields, or how it differs from the many sibling network/security tools, so it is not sufficient to invoke confidently.

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 no input is needed, and there is nothing further the schema could or should document.

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 ('active sockets') and the returned columns ('owning PID/process'), which is informative. But it is a noun phrase with no verb and gives no differentiation from the adjacent sibling sec.listening, so an agent cannot tell from the text alone which of the two returns established/active connections versus listening ports.

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 call this versus sec.listening, sec.exposure, or net.portscan. The description gives no context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.

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

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

No annotations, so the description carries the full behavioral burden and it barely does: it doesn't say whether the tool actively probes targets or only aggregates existing/local state, whether it requires elevated privileges to read firewall configuration, how long it takes, or whether it is read-only. The only behavioral hint is the implied read-only 'report', which is thin for a zero-annotation 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?

A single front-loaded line with no filler; the × and ⇒ notation compresses 'correlates these inputs into findings' efficiently. Nothing to trim.

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-param aggregate tool with no output schema, the description should at least sketch what a Finding contains and how the correlation is scoped (local host? LAN? current snapshot?), since there is no schema to fall back on. Naming 'Finding[]' without any description of its fields leaves a real 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?

Zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly avoids inventing parameter meaning that doesn't exist.

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 (a composite security report) and enumerates the three inputs it correlates: exposed listeners, firewall state, risky ports. That distinguishes it from the single-signal siblings sec.listening and sec.firewall. It stops short of a plain verb but the purpose is unambiguous.

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

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

The word 'composite' implies this is for an aggregate posture assessment rather than a single check, which weakly routes the agent away from sec.listening/sec.firewall. However, it never explicitly says when to use this versus those siblings, nor any prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the full disclosure burden. It hints at read-only behavior via "state" and usefully discloses that the underlying mechanism differs per OS, but says nothing about privilege requirements (ufw and socketfilterfw queries typically need elevated rights), failure modes on unsupported platforms, or what the returned state contains.

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 line with the resource stated first and the platform enumeration in a parenthetical. Nothing is padded, though the terseness tips into under-specification rather than economy.

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

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

For a zero-parameter, read-only status tool the complexity is low, and the description covers the platform dimension. But with no annotations and no output schema, it should still say what "state" comprises and flag that results may require elevated privileges or be unavailable on some hosts.

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. The parenthetical does add the useful note that the backend varies by platform, which explains why no arguments are 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 fragment names the resource and its content ("Firewall profile state") and enumerates the per-platform backends (win profiles / ufw / socketfilterfw), so an agent can tell roughly what comes back. However, it is a noun phrase with no verb and no statement of scope (profiles only? rule listings? enabled flag?), which keeps it in vague-purpose territory rather than a crisp verb+resource claim.

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 statement of which situations call for a firewall check, no mention that it complements siblings like sec.exposure or sec.listening, and no exclusions. The only implicit signal is that it is the sole firewall-oriented tool among the net/dns/lan/wifi/sec siblings.

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

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

With no annotations, the description carries the full burden and does not say whether this is read-only, whether it requires elevated privileges to resolve per-process ownership, which OSes it supports, or how long it takes. It conveys the concept but not the operational traits that would affect invocation.

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 clause with no filler, and the key qualifier (non-loopback exposure) is placed where it will be read. It is terse to the point of being a fragment rather than a sentence, but nothing is wasted.

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 phrase roughly sketches the return shape (per-process listening ports with exposure flags), which matters since there is no output schema. However, it leaves the agent guessing about field names, sorting, and how results are grouped, so it is only minimally sufficient for a zero-param tool with no annotation or output-schema support.

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 and the schema is empty at 100% coverage, so there is nothing for the description to clarify. Baseline 4 applies for a no-arg tool.

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

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

The description names a specific resource and scope: listening sockets enumerated per owning process, with non-loopback exposures flagged. That distinguishes it in practice from net.portscan (remote scanning) and sec.connections (established connections), though it never names a 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?

No when-to-use cue, no prerequisites, and no routing against the many adjacent siblings (sec.connections, sec.exposure, net.portcheck, net.portscan). The agent must infer that this is the local-audit option rather than a remote probe.

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, so description must convey behavior. It discloses rate limiting (1/min) and that the test is 'bounded' and uses Cloudflare by default, which are useful behavioral traits. However, it doesn't explain what 'bounded' means (e.g., data cap or time limit) or whether any permissions are needed.

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

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

Two short sentences, front-loaded with the core function and key constraint. No wasted 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?

For a zero-parameter tool with no output schema, the description covers the essentials: what it does and a key constraint (rate limit). However, the mention of 'configurable' is confusing since there are no parameters, and 'bounded' remains undefined.

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?

No parameters, so semantics are not applicable; baseline 4.

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 'download speed test' as the core action, distinguishing it from other network diagnostic siblings which don't perform speed tests. However, it doesn't explicitly contrast with alternatives, and 'bounded' is somewhat vague.

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

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

No indication of when to use this tool versus other network tools (e.g., net.health, net.ping). The rate limit is mentioned but not as usage guidance or exclusion criteria.

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

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

No annotations are provided, so the description carries the full disclosure burden. It implies a read-only derived analysis via 'interpretation ⇒ Finding[]', but never says whether it triggers an active scan or reads existing data, whether any privilege is required, how long it takes, or why zero parameters are sufficient (no interface selector).

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 line, front-loaded with the resource and followed by the analysis dimensions and return type. The '⇒ Finding[]' shorthand is efficient but slightly cryptic for a reader who doesn't already know the Finding type.

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?

It names the return type (Finding[]) but does not describe what a Finding contains (severity? referenced SSID/BSSID? suggested remediation), and with no output schema that information exists nowhere else. For a zero-parameter, zero-annotation diagnostic tool, one more clause on the output shape would make it 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?

The tool takes zero parameters, so there is no parameter semantics to explain; the implicit claim that analysis is performed over all WiFi state is consistent with the schema. Baseline 4 applies for a parameterless 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?

States a specific verb and resource ('WiFi interpretation') and enumerates the analyses it performs (RSSI bands, channel overlap, band mismatch), which distinguishes it from the raw-data siblings wifi.status and wifi.networks. The only weakness is that 'interpretation' is slightly abstract versus a plainer verb like 'diagnose'.

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 statement and no mention of the obvious alternatives (wifi.status for raw signal data, wifi.networks for the scan list). The agent must infer from the name alone that this is the diagnostic layer rather than the data-collection layer.

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

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

No annotations are provided, so the description carries the full burden, yet it says nothing about whether this is an active scan, how long it takes, whether location/privilege permissions are required, or how often results can be sampled. 'Survey' hints at active scanning but does not disclose side effects or constraints.

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 noun phrase naming the action and the field list, with no filler. It is arguably over-terse, but nothing is wasted or buried.

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

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

For a zero-param read tool with no annotations and no output schema, the description covers what is returned but omits latency, permission requirements, and any caveat that results reflect only currently visible APs. Adequate but clearly short of 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?

The tool takes zero parameters, so the baseline is 4; the description correctly implies a no-argument call by framing the tool as a scan rather than a query with filters.

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 ('Nearby AP survey') and enumerates the fields produced (SSID, BSSID, band, channel, security), which implicitly separates it from wifi.status/wifi.health that concern the current connection. It does not explicitly name those siblings, so differentiation is inferable rather than stated.

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

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

There is no statement of when to run this versus wifi.status or wifi.health, nor any precondition (e.g., needing a scan rather than reporting the joined network). The agent must infer usage purely from the word 'survey'.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the return payload (useful given there is no output schema), and 'Current WiFi link' implies a read-only snapshot, but it says nothing about behavior when no WiFi link is active, platform/permission requirements (e.g. SSID access restrictions), or latency.

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 that front-loads the resource and then lists payload fields. No filler or redundancy.

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, no annotations, and no output schema, the field list is the most important piece of context and it is present. The remaining gap is the disconnected/error case and any permission caveats, which an agent would want before relying on it.

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 to document; the description correctly does not invent any. Baseline 4 applies for a parameterless tool.

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

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

The description names a specific resource ('Current WiFi link') and enumerates the exact fields returned (SSID, BSSID, band, channel, RSSI, PHY rate, quality), which implicitly separates it from wifi.networks (a scan of nearby APs) and wifi.health. It lacks an explicit verb and never names those siblings, so the differentiation is inferred rather than stated.

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

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

There is no when-to-use guidance and no mention of the closely related siblings wifi.networks and wifi.health. An agent must guess whether this reports the connected link only or also nearby networks, and whether to prefer wifi.health for diagnostics.

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