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 behavioral: no statement that this is a read-only lookup, no scope limits (local subnet only, cached entries, staleness), no output shape. The phrase 'has learned' hints at cached/dynamic state, which is the only real behavioral signal.

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 short, front-loaded sentence with no filler or repetition. It is efficient, though a fragment rather than a complete statement of 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?

An output schema exists and the tool is parameterless, so the description needn't explain return values. Still, it omits the read-only nature and entry scope, which are the only things an agent would need beyond the schema — leaving it minimally adequate.

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

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

The tool takes zero parameters, and the description correctly implies a no-argument retrieval with no filtering options. Baseline 4 applies since there is nothing to 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 precisely — IP-to-MAC pairs learned on the local network — which is clearly the ARP table and distinguishably not route_table or interfaces. But it is a bare noun phrase with no verb, so it reads as a description of return data rather than stating what the tool does (retrieve/return the table).

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 call this versus siblings like route_table, ip_config, or interfaces, all of which overlap in the local-network diagnostics space. The agent must infer usage from the sentence alone; there are no exclusions or alternative routing hints.

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 says the tool diagnoses layers and suggests fixes, but it does not disclose whether it performs active network probes, requires permissions, has timeout or rate-limit behavior, or is strictly read-only.

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 purpose is front-loaded in one clear sentence, followed by only the necessary parameter notes. There is no redundant or filler text.

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

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

The description gives enough to invoke the tool with target and port, and an output schema exists so return values need not be explained. However, for a composite diagnostic surrounded by many single-purpose network siblings, it should explicitly clarify when to use this tool versus those alternatives.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: target is explained as a host name or IP address with an example, and port is explained as the TCP service port with 443 as the website example. The schema defaults are not mentioned, but the core semantics of both parameters are clear.

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 and outcome: run a full bottom-up diagnosis against a site and report which layer fails plus how to fix it. The phrase 'full bottom-up diagnosis' implies a composite check distinct from single-purpose siblings, though it does not explicitly name alternatives.

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 'against a site' and the target example of a host the user is trying to reach. However, the description never states when to choose this composite diagnostic over siblings like ping, traceroute, dns_lookup, port_check, or http_check.

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

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

No annotations exist, so the description carries the full burden. It discloses the resolution mechanism (system DNS vs. explicit server), which is useful, but says nothing about failure modes (NXDOMAIN, timeouts), whether the query is read-only/safe, or what the response 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?

One front-loaded sentence plus a compact Args block; no filler. The Args section is slightly redundant in style but earns its place given the empty schema descriptions.

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 says what comes back (list of A/AAAA records? ordering? address family?). For a lookup tool this is a real gap, though the call mechanics are otherwise clear.

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 docstring Args block does real work: it defines 'name' as a host name with an example and 'server' as an optional DNS server IP used instead of the system's own. Both parameters are covered, though the accepted format of 'server' (port? hostname?) is not stated.

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: resolve a host name to IP addresses, with the system resolver or an explicit server. That is clearly distinct from ping/traceroute/port_check siblings, although the description never names or contrasts them.

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

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

The phrase 'or with a given DNS server such as 1.1.1.1' implies when the optional server argument is worth supplying, but there is no explicit when-to-use/when-not guidance or comparison against siblings like ping or http_check that also trigger resolution.

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 outputs (status code, response time), which is valuable given there is no output schema. However, it omits timeout behavior, redirect following, whether the body is downloaded, and any failure-mode or rate-limit context an agent would want before probing an endpoint.

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

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

Two sentences plus a single-argument block, front-loaded with what the tool does and immediately followed by the parameter detail. No padding or repetition.

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

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

For a single-parameter diagnostic with no output schema and no annotations, the description covers purpose, the returned values, and the scheme default. It is close to complete; only timeout/redirect/error behavior is left to be discovered at runtime.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it gives an example value and, critically, the default behavior that 'https is assumed if no scheme is given'. That is exactly the kind of semantic the bare `string` schema does not convey.

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 ('Request a web page's headers') plus the two outputs ('HTTP status code and response time'), which is far more precise than a bare name. It implicitly separates itself from the raw-network siblings (ping, traceroute, port_check) by being an application-layer HTTP probe, 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?

The usage is only implied by the purpose: an agent can infer this is for checking whether an HTTP endpoint responds and how fast. There is no explicit 'use this instead of port_check when...' or 'use when you need an application-layer response rather than TCP reachability', and no exclusions or 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?

With no annotations, the description carries the full disclosure burden. It does imply a non-mutating enumeration and tells the agent what data categories come back, which is real value, but it says nothing about privileges needed, whether interfaces are discovered locally vs remotely, or whether results include down interfaces by default. Not contradictory, just thin.

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 the verb first and the returned fields packed into one efficient clause. No filler, no restatement of 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?

For a no-argument read tool with an output schema already documenting return values, this is nearly complete. The only gap worth naming is whether down interfaces are included and what scope of host is inspected, both of which would affect interpretation of results.

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 with 100% schema coverage, so the baseline of 4 applies. The description adds no parameter information because there is none to add.

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?

Opens with a specific verb and resource ('List network interfaces') and enumerates exactly what is reported: up/down state, IPv4/IPv6 addresses, MAC, speed and error counters. The parenthetical 'physical and data link layers' hints at how it differs from the IP-focused sibling ip_config, but the differentiation is left implicit 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?

Usage is only implied by the enumeration of link-layer fields; there is no explicit 'use this when...' and no sibling is named, even though ip_config, arp_table and wifi_signal all overlap in the network-diagnostics space. An agent can infer this is the interface-inventory call, but must reason it 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?

With no annotations, the description must carry behavioral load, and it does disclose the key trait: scope is strictly local ("This computer's") and limited to IPv4. It does not state that the operation is read-only, whether it can fail or return partial data, or how the output is structured, which are notable omissions for a diagnostic 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?

One front-loaded sentence that names the returned fields first and adds the analogy last as reinforcement. No filler, 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?

There is no output schema, and the description compensates by enumerating the returned data (IPv4 addresses, gateway, DNS). The IPv4-only restriction is stated, which is the main completeness risk. Minor gap: no mention of what happens if networking is down or how addresses are ordered.

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 disambiguate and the baseline of 4 applies. The description correctly exposes no input surface an agent could misuse.

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 (this machine's IPv4 addresses, default gateway, DNS servers) and anchors it to the familiar `ipconfig` command, so an agent knows exactly what comes back. It is not differentiated from the sibling `interfaces` or `route_table`, which overlap on address/gateway 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?

No when-to-use or when-not-to-use guidance; the only hint is the `ipconfig` analogy, which implies a quick local lookup. Nothing tells the agent whether to prefer this over `interfaces` for interface enumeration or `route_table` for the gateway, so the choice 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?

With no annotations, the description carries the full behavioral burden. It does disclose the return content (replies, packet loss, latency, jitter), which is genuinely useful, but says nothing about blocking duration, timeouts, failure behavior, or the fact that this is a non-destructive read-only network probe. Decent but incomplete for an unannotated 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 operative sentence is front-loaded and dense with real information, and the Args block is short. There is mild redundancy in restating parameter titles the schema already exposes, but the added range limit earns its place.

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

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

For a two-parameter network probe with no annotations and no output schema, the description covers purpose, both parameters, and the shape of the result. It stops short of telling the agent what happens on an unreachable host or how long the call may block, which matters for a latency-bound 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%, so the description must compensate, and it does: both parameters are documented, and it adds a constraint absent from the schema (count is bounded 1 to 10) plus the meaning of host as name-or-IP. Only minor gaps remain, such as units or behavior at the bound.

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 verb and resource ("Ping a host") and goes further by naming the measurements returned: replies, packet loss, average latency and jitter. That distinguishes it in substance from siblings like traceroute or dns_lookup, though it never names those alternatives 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 only implied: an agent can infer this is for reachability/latency checks against a single host, but the description never says when to prefer it over traceroute (path), port_check (service), or dns_lookup (resolution). No prerequisites, exclusions, or preconditions 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?

No annotations exist, so the description carries the full burden. It does disclose the important behavior — a real handshake is attempted and the three possible result states are enumerated — but says nothing about timeout duration, whether results are cached, or what a slow/filtered port yields versus a timed-out one.

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 sentence states purpose and outcomes, followed by a compact Args block. No filler and no repetition of schema metadata.

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 two-parameter diagnostic tool with no output schema and no annotations, the description covers purpose, both parameters, and the shape of the result. Only timeout/timing expectations are missing, which is a minor gap for an agent deciding whether to wait on the call.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: host is defined as hostname or IP, and port is defined with concrete examples (443/HTTPS, 80/HTTP, 53/DNS) that implicitly clarify it takes a numeric TCP port. It does not restate the 443 default already in the schema, which is appropriate.

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 precise mechanism (TCP three-way handshake) against a precise target (host:port) and states what is reported (open, refused, timed out). That mechanism framing alone separates it from ping (ICMP) and http_check (application layer) in the sibling list, so an agent can pick it without opening the 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: an agent can infer this is the tool for 'is this TCP port reachable'. There is no explicit when-to-use statement, no exclusion, and no mention of the closest alternatives (http_check for a full HTTP request, ping for host liveness).

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 must carry the full behavioral burden, yet it omits that this is a read-only, no-argument, local-host query and that it returns nothing about remote targets. It does at least scope the data to 'the computer's' own table rather than a remote host, which is a meaningful constraint.

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 sentence with zero filler, front-loaded on the resource. Its brevity flirts with under-specification rather than waste, but nothing in it fails to earn 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 zero parameters and an output schema covering return values, the bar is low, and the description adequately identifies the data. However, for a diagnostic toolset this dense, it leaves the agent without a reason to pick this over ip_config or arp_table.

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; there is nothing for the description to explain and it correctly implies no inputs 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 description names the resource (the routing table) and adds one substantive detail (default route 0.0.0.0/0), but it is a noun phrase with no verb, so the action (retrieve/display) is only inferred. It never contrasts itself with the adjacent siblings ip_config or arp_table, which an agent could easily confuse with routing information.

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 ip_config, arp_table, or traceroute, and no mention of prerequisites or context. The agent must infer usage purely from the tool 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?

With no annotations, the description carries the full behavioral burden, and it says nothing about expected duration, hop timeouts, whether non-responsive hops are skipped or shown, or that the operation is a harmless read. 'Where the replies stop' gestures at the result shape but doesn't disclose operational 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 tightly packed statements with zero filler, and the core behavior is front-loaded before the Args block. The Args formatting is slightly mechanical but costs little.

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

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

A simple two-parameter, no-output-schema tool, so the bar is modest, but with no annotations the definition should at least flag cost/latency or the read-only nature and what happens with unresponsive hops. The essential call information is present and correct.

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 partially does: it clarifies host as a name or IP and adds the 1-30 bound for max_hops that the schema does not encode. It omits the default (15), which only the schema's 'default' field 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?

States a specific verb and resource: 'List every router on the path to a host', plus the outcome it surfaces ('where the replies stop'). This is clearly distinct from siblings like ping and route_table in practice, though the description never names or contrasts them.

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 or when-not-to-use guidance, and siblings such as ping, route_table, and diagnose are not mentioned. However, 'where the replies stop' implies the diagnostic scenario (finding where connectivity breaks), giving implied rather than stated usage.

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 units (dBm) and the derived qualitative rating, which is real behavioral value. The critical gap is what happens when the machine is not on Wi-Fi — error, empty result, or message — which is left ambiguous for an agent deciding whether to call 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 sentence with the measurement, units, rating scheme, and applicability condition all front-loaded. No filler, 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 zero-argument read tool with no output schema, naming the return values and units is close to complete. The only missing piece is the non-Wi-Fi failure mode, which matters for result interpretation but not for invocation.

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 does not need to explain any inputs and correctly spends its words on output semantics instead.

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 (Wi-Fi signal strength) and pre-describes the return shape (dBm value plus strong/ok/weak rating), which no sibling tool covers. It is clear against siblings like interfaces or ip_config by virtue of the wireless-specific metric, 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?

The clause 'if the computer is on Wi-Fi' communicates a precondition, implying this is a wireless-connectivity diagnostic. However, it offers no when-to-use guidance versus siblings such as interfaces or ping, and no statement about what to do for wired hosts.

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