x402 Checker (AI Nock)

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

The description discloses the paid nature ($0.01 USDC on Base) and the payTo address, as well as the 366-day cap and holiday coverage. It does not explicitly state read-only behavior, but the annotations provide readOnlyHint. Payment details are transparent, but side effects like the payment process are not fully explained.

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 concise and structured as a single statement with key details embedded. It avoids unnecessary verbosity but is somewhat dense, packing multiple facts into one sentence.

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 covers payment, calendar scope, and parameter constraints, but lacks explicit information about the output format or how the payment is executed. Given the tool's complexity (paid and blockchain-related), the description is not fully complete but covers essential operational aspects.

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 description explains the usage of date, start, and end parameters, including defaults and caps. It does not mention the tz parameter, but the schema provides its description. Overall, parameter semantics are well-covered.

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 indicates this tool provides US federal business-day calendar information, mentioning holidays and weekday rules. However, it does not explicitly state the exact output (e.g., count, boolean, or list), so the purpose is clear but not fully specified.

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 the sibling tools. There is no mention of alternative use cases or comparative advantages, leaving the user without 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses that no payment headers are sent, that the tool is free, and that it does not spend money. It also describes the response shape, including the conditional 'next' object and short risk note, adding substantial behavioral context.

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

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

The description is compact and front-loaded, with three focused sentences covering purpose, behavior, return data, and safety. Minor redundancy exists between 'FREE' and 'does not spend money,' but it remains appropriately sized and scannable.

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 a single parameter and no output schema, the description adequately explains what the tool returns, when the conditional next object appears, and the cost implications. It covers the essential decision context for an agent selecting and using this 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?

The schema already documents the url parameter and confirms no payment headers are sent, but the description adds context that this URL is for x402 inspection and that it should be used before paying. This raises it above the baseline of 3 despite the high schema coverage.

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

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

The description states a specific verb and scope: 'Fetches an http(s) 402 URL with no payment headers' as an 'x402 wash/honesty probe.' It clearly identifies the tool's purpose and differentiates it from likely siblings by emphasizing pre-payment inspection of x402 resources.

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 explicit usage context: 'Use before paying any x402 resource.' It also signals that the tool is safe because it 'does not spend money.' It does not list when-not-to-use or name alternatives, so it just misses 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?

The description discloses important behavior beyond the readOnlyHint/openWorldHint annotations: it mentions the $0.01 USDC payment on Base and the payTo address. It also enumerates the data sources, but it does not clarify error cases or whether the payment is external to the MCP request.

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 compact, front-loads the payment requirement, and uses one dense sentence plus the payTo address. There is no filler, repetition, or unnecessary 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 single-parameter, read-only tool with no signed output schema, the description provides enough information to choose the tool and invoke it: what data is covered, that payment is required, and the expected input. A brief statement of the response format would have made it fully complete, but the description is 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 input schema already fully defines the host parameter as a public DNS hostname, not a URL or IP. The tool description adds no new parameter insight; it mostly repeats the same wording. Baseline 3 is appropriate because schema coverage is high.

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 the tool's output: a DNS/RDAP/TLS/SPF/DMARC dossier for a public hostname. It distinguishes the tool's scope from siblings by naming the data sources, but it does not use an explicit verb like 'returns' or explicitly compare it to 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: call this tool when you need domain-related data from DNS, RDAP, TLS, SPF/DMARC. There is some payment context and a public-hostname constraint, but no explicit guidance about when to prefer another tool or when not to use it.

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 provide readOnlyHint and openWorldHint, but the description adds substantial behavioral detail: payment requirement and exact payTo address, DNS-over-HTTPS mechanism, no SMTP, disposable-domain and MX-absent invalidity, and fail-closed error handling. This richly exceeds the annotation baseline.

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

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

The description is one dense, front-loaded sentence with no filler. Every clause conveys essential operational or validation information.

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

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

For a single-parameter validation tool with no output schema, the coverage is strong: behavior, failure mode, and payment requirement are all stated. The only gap is the absence of any hint about the return value or response format, which the lack of an output schema makes somewhat relevant.

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% for the single 'addr' parameter, and the description adds meaning by defining what makes an address invalid (disposable domain, missing MX). This directly informs which parameter values the tool will accept or reject.

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 communicates the tool's function: validating email syntax and MX records via DNS-over-HTTPS, with no SMTP. It is specific enough to distinguish from sibling tools like 'domain' or 'check', though it lacks an explicit verb like 'validate'.

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 implies usage context by specifying constraints: email only, no SMTP, paid $0.01 USDC, and fail-closed behavior. However, it does not explicitly state when to prefer this tool over alternatives or name any sibling tools for comparison.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds context about the payment (Paid $0.01 USDC exact on Base) and that it's a raw dump, not markdown. This adds value beyond annotations, though it doesn't detail rate limits or auth needs.

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 concise, with two sentences that front-load the purpose and add key context. It earns its place without unnecessary fluff.

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 the tool's simplicity (one parameter, no output schema), the description is mostly complete. It covers the purpose, payment, and a key behavioral note, but could benefit from mentioning what the output looks like or any limitations.

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 the single 'url' parameter, and the description adds that no payment headers are sent to the target, which is useful. However, the description doesn't elaborate on URL format or edge cases beyond 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 clearly states the tool performs a raw HTTP header dump of a public URL, which is a specific verb+resource. It also distinguishes itself from siblings by explicitly noting it is not an honesty probe or markdown, though it doesn't name specific sibling 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?

The description implies usage for inspecting HTTP headers of a public URL, and the schema notes no payment headers are sent. However, it doesn't explicitly state when to use this over alternatives or when not to use it, leaving some ambiguity.

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 declare readOnlyHint=true, indicating a read-only operation, and the description does not contradict this. The description adds context about the tool's limitations (tiny subset, no $ref) and payment requirement, but does not clarify what the tool actually outputs or whether errors are returned for invalid 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 sentence, concise and front-loaded with the action and payment. It conveys key information, though the payment address inclusion may be seen as unnecessary detail, but it does not harm conciseness much.

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 the tool's moderate complexity, the description covers purpose, key constraint (subset, no $ref), and payment requirement. No output schema is needed as the tool is likely to return validation results, but the description is brief; still, it is sufficient for basic usage.

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 parameters are documented with descriptions like 'JSON instance object or JSON text' and 'JSON Schema object or JSON text'. However, the description does not add further semantic detail beyond what the schema provides, so 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?

Purpose is clear: validate JSON data against a JSON Schema, specifying it's a tiny built-in subset with no $ref, and mentioning it is paid on Base. This distinguishes it from sibling tools like 'check' and 'domain', which are not about JSON validation.

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 implies usage for validating JSON data, but does not explicitly state when to use this tool versus alternatives, nor when not to use it. It mentions the paid nature and payment address, which is a contextual usage hint, but lacks direct guidance on choice among 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?

The description adds meaningful context beyond the annotations: it discloses a $0.01 USDC payment requirement, a payTo address, and the 'public URL' constraint. The readOnlyHint and openWorldHint annotations are not contradicted. It does not explain payment mechanics or error behavior, but the added context is valuable.

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 short, but the payment phrase is front-loaded awkwardly before the actual verb, and the payTo address appears as a detached second sentence. It is not verbose, but the structure could better prioritize the core 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?

For a one-parameter tool with annotations and no output schema, the description covers purpose, return type, and payment context. However, the payment requirement is ambiguous ('Paid $0.01 USDC exact on Base' could mean already paid or required), and there is no mention of error handling, redirects, or content limitations.

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 url parameter is already described as an 'http(s) URL to inspect' with no payment headers sent. The tool description adds only the word 'public' and the output format, which is marginal beyond the schema. 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?

The description clearly states a specific action: 'fetch a public http(s) URL and return simple HTML-to-text markdown.' This distinguishes it from sibling tools like headers, json, and domain. The payment prefix is unusual but does not obscure the core purpose.

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: use this tool when you need HTML-to-text markdown from a public URL. However, there is no explicit when-not-to-use guidance or mention of alternatives among the sibling tools. The payment requirement is a usage condition but is not framed as a selection 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?

The description discloses a payment of $0.05 USDC and mentions 'PAYMENT-REQUIRED' and 'should-pay note', which implies side effects beyond a typical read-only operation. However, it does not explain the payment mechanism, potential costs, or the exact behavior when interacting with the target URL, despite the readOnlyHint annotation.

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 run-on sentence mixing unrelated terms (payment, x402, payTo) and lacks clear structure. It is not concise or organized, making it difficult to parse and understand.

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 is incomplete for a tool involving payments and external lookups. It does not explain what 'x402' means, how the payment is executed, what a 'should-pay note' indicates, or what the output will be (no output schema). The complexity is not matched by sufficient contextual detail.

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 already provides a clear description for the 'url' parameter ('http(s) URL to inspect. No payment headers are sent to the target.'). The tool description adds no further meaning or constraints for this parameter, so it does not enhance the schema's coverage.

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

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

The description is vague and does not clearly state what the tool does. It mentions 'deeper x402 lookup' and 'REST GET /report' but fails to explain the tool's core functionality or how it relates to the URL parameter. The purpose is obscured by cryptic references to payments and x402.

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 offers no guidance on when to use this tool versus the sibling tools (e.g., check, headers, json). It does not mention specific scenarios, prerequisites, or alternatives, leaving the user without context for appropriate invocation.

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?

Exceeds the annotations by disclosing 'Paid $0.01 USDC', 'Fail closed' failure handling, 'Not legal advice' limitation, and the payTo address. The description proactively discloses important behavioral and commercial traits that annotations don't cover, with no contradictions.

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

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

Two compact sentences deliver cost, purpose, address formats, error behavior, and a legal disclaimer without unnecessary words. Every element earns its place, effectively front-loading the most critical information (the fee).

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 output schema, the description fails to specify the return value or response format, which is a major gap for an agent to use the result. While 'Fail closed' provides some clue about error behavior, a complete tool contract would state what the success response looks like (e.g., boolean or structured 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?

The schema already describes the single parameter with 100% coverage, including the address format. The tool description echoes this information but adds no premium semantic content beyond that, conforming to the baseline-3 expectation.

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 sanctions screening tool for crypto addresses on OFSD SDN, mentioning specific address formats ('EVM 0x or Solana/base58'). It stands out from sibling tools by explaining the exact service and payment, making the purpose 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?

Provides clear usage context by stating the cost ($0.01 USDC), the network (Base), and the supported address types. However, it does not explicitly mention when not to use it or name any alternative tools, so it falls 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 declare readOnlyHint and openWorldHint, and the description adds meaningful behavioral context by mentioning a specific payment requirement and recipient. However, the phrasing 'Paid $0.01 USDC exact on Base' is ambiguous about whether payment is required beforehand, who pays, or how the payment mechanism works.

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 concise, packing the returned fields and a payment recipient into two short sentences. However, the most important functional content is not front-loaded; the payment clause appears first, making the structure slightly awkward for an agent scanning for 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?

For a one-parameter tool with no output schema, the description usefully lists the four returned data points (isContract, ETH balance, USDC balance, tx count). Still, it lacks clarity on the payment prerequisite and invocation flow, and provides no response shape or broader usage context, so it is only minimally 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 schema already provides 100% coverage for the single address parameter, including format and chain details. The description merely repeats 'for an address' and does not add new parameter-level constraints, defaults, or edge cases beyond what the schema documents.

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 specifies the tool returns on-chain metrics for an address (isContract, ETH balance, USDC balance, tx count), which is more specific than the bare name 'who' and distinguishes it from sibling tools like sanctions or domain. It lacks an explicit verb such as 'returns' and buries the core purpose behind a payment clause, but the functional intent is still clear.

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 such as check, email, or sanctions. The description simply says 'for an address' with no conditions, exclusions, prerequisites, or mention of alternative tools, leaving the agent to infer appropriate usage.

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