sitecheck

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

With no annotations, the description carries the full behavioral burden but only implies a read operation. It does not state whether the call requires authentication with the same key, whether it consumes quota, what units the balance is in, or what happens for an invalid key.

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

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

A single front-loaded sentence with no waste. It is appropriately sized for a one-parameter lookup, though it is so brief that it sacrifices helpful detail for brevity.

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

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

The tool is simple, has one fully documented required parameter, and no output schema, so the description does not need to explain return values. However, for a tool with no annotations it leaves the behavioral profile (auth, side effects, error cases) entirely 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?

There is a single parameter with 100% schema description coverage, so the schema already documents 'key' as the API key. The description adds nothing about the parameter and does not need to, 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?

The description states the resource ('balance of an API key') but has no verb and does not differentiate from siblings such as create_key or check_domain, which are far apart in function. An agent can infer it is a lookup, but the phrasing is terse and would not distinguish it from a hypothetical sibling that also reports key attributes.

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, no mention of prerequisites, and no alternatives named. The agent must infer that this is a plain read of a key's remaining quota.

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

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

With no annotations, the description carries the full burden and does well: it discloses that lookups are live, that no API key is required, the rate limit (5 free calls/day across all tools), and the cost model (0.01 USDC per call via a prepaid balance). It does not cover latency, failure behavior, or caching, but the auth and rate-limit context is exactly the kind of thing annotations would normally provide.

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?

Opens with a front-loaded framing question, then the capability list, then the use case, then operational constraints — a logical order. The capability enumeration is long but each item is a distinct return value the agent would want to know, so it earns its space.

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, so the description must describe returns — and it does, listing the concrete categories of findings. Combined with the auth/cost constraints, an agent has everything needed to call this 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 the baseline is 3. The description does add billing meaning for `key` ('pass `key` to use a prepaid balance (0.01 USDC per call)') beyond the schema's 'Optional API key from create_key'. `domain` is only implied, but the schema already documents it as a public hostname.

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/vet) and resource (domain) and enumerates exactly what it returns: RDAP registration age and registrar, DNS, SPF/DMARC, TLS certificate health, redirect chain, security headers, and plain-language findings. This aggregates and clearly exceeds the narrower siblings (domain_registration, email_auth, tls_certificate), so an agent can distinguish 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?

Gives a concrete use case: 'vet a merchant, sender or link before trusting it.' That is clear context for selection. It does not, however, name the narrower alternatives (domain_registration, email_auth, tls_certificate) or state when to prefer them, so there is no explicit exclusion guidance.

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

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

No annotations are provided, so the description carries the burden. It discloses that this is a credit/mutation operation and adds a critical success condition about the amount's decimals matching the key tag, but it omits error behavior, idempotency, or return details.

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 purpose and followed by 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?

For a single-parameter tool with no output schema or annotations, the description covers the operation and the unique amount/tag requirement. It does not explain what is returned or how failures are signaled, but it is sufficient for an agent to select and invoke the 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 100%, so the schema already fully documents the single `tx` parameter. The description adds no additional parameter-level meaning, making this a baseline 3.

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

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

The description states a specific verb and resource: crediting a key after sending USDC on Base. It clearly distinguishes the action from siblings like create_key or balance, though it does not explicitly name an alternative.

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

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

It provides a clear prerequisite: the USDC must have been sent on Base, and the amount's last four decimals must match the key's tag. It does not mention when not to use it or name alternative tools, but the context is sufficient.

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 usefully discloses an effect beyond the name — the response includes funding instructions and the key is tied to USDC on Base — but says nothing about auth requirements, whether the key is shown only once, or whether creation is reversible.

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

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

Two short sentences, front-loaded with the action and followed by the practical caveat about the free limit. 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?

With no parameters and no output schema, the description does tell the agent what comes back and who needs it, but it omits prerequisites (email auth?), the funding requirement, and whether the key is retrievable later — meaningful gaps for a credential-creating mutation.

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 disambiguate. No score credit is lost here.

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 ('Create an API key') and adds the secondary outcome (funding instructions for USDC on Base). It is distinguishable from siblings like balance or domain_registration, though it never relates itself to email_auth or the other account tools.

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?

'Only needed beyond the free limit' gives a rough gating condition, but it never names what to use instead, what counts as the free limit, or any prerequisite (e.g., whether email_auth must run first). Usage is implied rather than explained.

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 delivers the two facts an agent most needs operationally: a rate limit (5 free calls/day across all tools) and a cost model (pass `key` for a 0.005 USDC prepaid balance). It does not say what happens on a nonexistent or invalid domain, so error behavior remains undisclosed.

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 sentences, front-loaded with what is returned, then when to use it, then the cost constraint. The field enumeration is long but each item is informative; nothing is redundant padding.

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

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

With no output schema and no annotations, the description compensates by enumerating the returned fields and stating the pricing/rate-limit model. The only meaningful gap is failure semantics for bad or unregistered domains, which an agent would want before relying on the result.

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% for both parameters, so the baseline is 3. The description adds only marginal value, clarifying that `key` draws on a prepaid balance, while `domain` semantics are left entirely to 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?

The description names the specific resource (RDAP domain registration data) and enumerates the returned fields — registrar, dates, age, status flags, nameservers, DNSSEC — which is far more specific than the tool name alone. It never names a sibling, so an agent must infer on its own that this differs from check_domain or tls_certificate, which keeps it short of a 5.

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

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

"Use it to spot a newly registered or soon-to-expire domain" gives a concrete decision context for invoking the tool. It stops short of explicit exclusions or naming the alternative (check_domain for availability), so it is clear context without routing guidance.

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

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

With no annotations, the description carries the full burden and does so: it discloses that lookups are live DNS queries, that the free tier is 5 calls per day across all tools, and the exact prepaid cost (0.005 USDC per call) when passing `key`. Rate limit, cost model, and the no-side-effect read nature are all surfaced.

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

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

Front-loaded with the core question and verdict, then the return inventory, then usage and billing. The enumeration of returned records is dense but every item is relevant signal for a DNS/email-audit tool; no filler sentences.

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, so the description must describe returns — and it enumerates them (records plus a spoofable verdict and findings). It also covers cost, rate limits, and the domain parameter semantics, leaving nothing an agent needs to call 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 coverage is 100%, so the baseline is 3; however the description adds real meaning about `key` that the schema does not — that it draws on a prepaid balance at 0.005 USDC per call, versus the 5 free daily calls. That is added value beyond the schema's 'Optional API key from create_key'.

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

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

It poses a concrete question ('Can mail from this domain be spoofed?') and then names the exact resources returned (MX, SPF strictness, DMARC, DKIM, MTA-STS, TLS-RPT, BIMI, spoofable verdict). An agent can distinguish this from siblings like check_domain or tls_certificate without opening any schema.

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

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

It gives two clear use cases: judging a sender's domain and auditing your own before sending. It stops short of naming alternatives (e.g., check_domain or tls_certificate) or stating when not to use it, so it is clear guidance without explicit routing.

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 largely does so: robots.txt compliance, no JS rendering, stripping of nav/ads/scripts, 'not charged if the page cannot be read', and rate/pricing limits (5 free calls/day, 0.005 USDC per call via prepaid key). These are non-obvious behavioral traits an agent must know before calling.

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?

Purpose and output shape are front-loaded, followed by constraints and then billing. Dense but every sentence carries information; the billing sentence is slightly packed but still 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?

No output schema and no annotations, yet the description covers what the return payload contains, what is stripped, rendering limitations, compliance behavior, and cost model. Nothing an agent needs to call it correctly is missing.

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 the schema already documents url, links, max_chars and key. The description adds only pricing/billing context for key ('pass key to use a prepaid balance') and does not explain links or max_chars behavior. Baseline 3 is appropriate when the schema does the heavy lifting.

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 web page') and enumerates exactly what is returned: title, description, language, publish date, and article text with headings, lists, tables, code blocks and links. This is far more specific than any sibling (balance, check_domain, create_key), so an agent can route to it unambiguously.

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

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

Gives clear intended context ('Built for LLM agents that need to read a URL') and meaningful exclusions: static HTML only, no JavaScript rendering, and robots.txt is respected. It does not explicitly compare against a sibling alternative, but the siblings are largely unrelated, so the boundary is inferable.

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 discloses the live-handshake behavior, the fixed port, the return surface, and — importantly — the commercial/rate-limit envelope: 5 free calls per day across all tools and a prepaid `key` option at 0.005 USDC per call. It does not cover failure modes (unreachable host, timeout, untrusted-cert response shape), which keeps it out of 5 territory.

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 sentences, no filler. The core behavior is front-loaded, the use case follows, and the pricing/rate-limit constraint is placed last where it belongs. Every clause — including the output list — earns its space given there is no output 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?

No output schema exists, so the description compensates by enumerating the returned fields, and it covers cost and access. What remains thin is error/failure behavior for a live network call (unreachable host, handshake failure, untrusted chains) — minor but a real gap for an agent that must interpret an empty or failed result.

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 the baseline is 3. The description earns above baseline by adding meaning the schema does not: `key` unlocks a prepaid balance at 0.005 USDC per call, and the target is implicitly fixed to port 443, which constrains how `domain` is used.

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 concrete action and resource: 'Live TLS handshake with a host on port 443', and then enumerates the exact facts returned (trust, issuer, covered names, protocol version, expiry, days left). The purpose is unmistakable. It stops short of an explicit sibling contrast, though the scope is clearly distinct from check_domain, email_auth, etc.

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?

'Use it to catch an expiring or misissued certificate' gives a clear use context. There is no when-not guidance and no named alternative, but none of the siblings (balance, create_key, check_domain, domain_registration, email_auth, read_url, claim_deposit) plausibly compete for the same task.

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