RunStack Checks

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

Annotations already establish readOnlyHint and openWorldHint, so the safety and external-network profile is covered. The description adds real behavioral detail beyond that: which resolvers are queried and that the response reports per-resolver answers and flags inconsistencies.

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

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

Three tight sentences: purpose first, then when to use it, then a return-value note. Every sentence carries information an agent can act on, with no repetition of the title or schema.

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

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

With no output schema, the description usefully summarizes the return shape (per-resolver answers plus inconsistencies). For a two-parameter read-only diagnostic it is nearly complete, though it says nothing about timeouts, partial resolver failures, or query cost/latency.

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

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

Schema coverage is 100% and the type enum is documented in the schema, so the baseline is 3. The description goes further by naming the resolver set (Google, Cloudflare, Quad9), which tells the agent that resolver selection is fixed rather than a parameter and frames how to interpret per-resolver output.

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 (resolve), resource (name), and an unusual scope (across several named public resolvers) with the added behavior of comparing answers. This distinguishes it immediately from sibling diagnostics like check_http, check_port, and ip_lookup, which probe different layers.

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

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

Gives two concrete triggering scenarios: verifying propagation after a DNS record change, and diagnosing users who see a different IP or NXDOMAIN. Strong when-to-use guidance, though it never names an alternative tool or a when-not condition (e.g. single-resolver or reverse lookups).

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds useful context: the 10-lookup count for SPF and that it reports cause+fix. But it does not disclose rate limits, timeouts, or whether checks run live, which matters for an open-world 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?

Two sentences, front-loaded with the audit scope, then the usage triggers, then the return shape. Every clause earns its place.

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

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

Covers purpose, triggers, checked records and return values (verdict, findings, report link). Missing only latency/rate-limit expectations for a live network audit; no output schema exists, but the return shape is described.

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

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

Schema coverage is 100%, so both parameters are already documented. The description adds no syntax or format details beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource (audit a mail domain) and enumerates exactly what's checked (MX, SPF, DKIM, DMARC, PTR/FCrDNS, SMTP STARTTLS, MTA-STS, TLS-RPT, BIMI). Clearly distinguishable from siblings like check_dns or check_tls, which cover a subset.

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

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

Gives three concrete triggering situations (spam/bounces, after provider or DNS changes, before tightening DMARC). No explicit exclusions or named alternatives, so a 4 rather than 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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds the meaningful vantage-point detail that the fetch happens from outside the caller's network, and that output is a verdict plus findings with fixes. It omits rate limits, timeouts, or handling of private/unreachable URLs, keeping it below a 5.

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

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

Two sentences, front-loaded with the core action and scope, followed by use cases and return shape. Every clause carries information; no filler or restatement of the title.

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

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

With no output schema, the description usefully sketches the return value ('a verdict and findings with fixes') and covers scope, vantage point, and use cases. It is essentially complete for a 2-param read-only check, though error/failure behavior for unreachable or private URLs is unstated.

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

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

Schema description coverage is 100%, so both parameters (url, followRedirects) are already documented in the schema, making 3 the baseline. The description adds no further parameter semantics — notably it never mentions the followRedirects option despite discussing redirect behavior.

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 ('Fetch a public URL from outside your network') and enumerates exactly what it inspects: status, redirect chain, TLS, security headers, caching, compression. Against siblings like check_tls and check_dns, the combined-scope nature of this check is immediately distinguishable.

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

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

Gives concrete when-to-use contexts: debugging redirect loops, wrong status codes, missing headers, or verifying a config change after deploy, all 'as real visitors and CDNs see them.' It does not explicitly name check_tls or check_port as the alternative for narrower checks, so the routing guidance stops just short of 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?

Annotations already cover readOnly and open-world behavior. The description adds real context beyond them: the three possible port states (open/closed/filtered) and the constraint that only public addresses are allowed. It omits rate limits and what error a private host produces, keeping it out of the 5 band.

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 verb and outcome set, followed by usage and then the key constraint. 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 output schema, the description helpfully defines the return vocabulary (open/closed/filtered) and the public-address restriction. It leaves the error behavior for non-public input unstated, which is the only meaningful gap for a 2-param 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 coverage is 100% — host is documented as a public hostname/IP and ports as a comma-separated list with an example. The description's 'public addresses only' adds a constraint but no new syntax or format detail, so the baseline of 3 applies.

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

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

States a specific verb (check), resource (TCP ports of a public host), and the outcome taxonomy (open, closed, filtered), and scopes it to internet-origin checks. This clearly distinguishes it from siblings like check_dns, check_http, or ip_lookup.

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

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

Gives concrete when-to-use triggers: verifying firewall/security-group rules and diagnosing a service reachable locally but not externally. It does not name sibling tools as alternatives, so it falls just short of the top band.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description reinforces the open-world nature ('from the internet') while adding genuinely new behavioral facts: the ~60 s runtime and the shape of the result (verdict, findings with cause and fix, shareable report link). It does not cover rate limits or failure modes, so it falls short of a 5.

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

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

Four tight sentences: purpose first, then when to use, then what it returns, then the latency caveat. Nothing is redundant and the most decision-relevant information is front-loaded.

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, but the description compensates by describing the return values (verdict, findings with cause and fix, report link) plus the runtime. Combined with annotations covering the safety profile, an agent has everything needed to select and 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 100%, so host and port are already fully documented in the schema. The description mentions protocol/cipher coverage but adds no parameter-level detail such as port syntax or defaults beyond what the schema states; baseline 3 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?

States a specific verb (Scan) and resource (a public host's TLS) with the exact facets covered: certificate chain, expiry, hostname match, protocols, ciphers, HSTS. This clearly separates it from siblings like check_dns, check_http, and check_port without needing to name 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?

Gives explicit triggering conditions: certificate errors, before/after renewing or rotating a cert, and confirming old TLS versions are disabled. Clear context, though it stops short of naming alternative sibling tools or stating when a different check (e.g. check_port) would be the better choice.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety and external-query behavior are covered. The description adds genuinely new behavioral content by naming what is retrieved — reverse DNS, RPKI validity, geolocation — which is the closest thing to a return-value contract given there is no output schema. It omits edge-case behavior (invalid input, private/reserved ranges, rate limits).

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

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

Two sentences, zero filler, front-loaded with the operation and its outputs before the usage guidance. Every clause earns its place.

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

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

With no output schema, the description usefully enumerates the returned data fields and gives usage context, which is enough to call the tool correctly. Missing only peripheral details such as failure behavior for malformed or private inputs.

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

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

Schema description coverage is 100% and the single 'input' parameter is documented in the schema as 'IPv4/IPv6 address or ASN like AS13335'. The description only restates 'IP address or ASN' with no additional format, normalization, or error guidance, so the baseline of 3 applies.

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

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

States a specific verb and resource ('look up an IP address or ASN') and enumerates the five data classes returned (owner org, prefix, PTR, RPKI, geolocation). The IP/ASN input scope naturally separates it from the check_* siblings, but no sibling is named, so it stops short of explicit differentiation.

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

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

Provides two concrete use cases: identifying who is behind an address seen in logs, and checking PTR/RPKI for a mail or BGP issue. That is clear when-to-use guidance, though there are no when-not conditions and no explicit routing to check_dns or the other siblings.

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