x402 Tools

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

With no annotations, the description carries the behavioral disclosure burden. It discloses the $0.02 per-call cost, the data sources (RDAP, DNS, crt.sh), and the read-only intelligence-gathering nature. It omits minor operational details such as rate limits, timeout behavior, or output formatting, but the core behavior is transparent.

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 cost and the bundle summary. Every clause adds information, and there is no filler 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?

The description enumerates exactly what data the tool returns (RDAP fields, DNS record types, CT history), which is valuable given there is no output schema. It lacks only a concrete q example and error-condition notes, which keeps it from being fully 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?

Schema coverage is 100%, so the baseline is 3. The description adds domain context to the generic q parameter, helping infer that q represents the domain to investigate, but it does not specify the exact accepted format or keys (e.g. plain domain vs 'domain=...').

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 purpose: domain due-diligence covering RDAP registrar data, DNS records, and Certificate Transparency history, with an explicit use case ('vet a domain before trusting or linking to it'). This clearly distinguishes it from siblings like free_url_check, github_repo, or web_fetch.

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 an explicit when-to-use instruction: vet a domain before trusting or linking to it. However, it does not name alternatives or specify when not to use it, so it stops just short of full 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 behavioral transparency burden, and it does disclose key behaviors: it follows redirects (final URL), returns limited metadata, and does not return full content. It does not mention timeout, error handling, or whether only HTTP(S) URLs are supported, but the core behavior is well disclosed.

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, front-loaded with the core purpose, and efficiently lists outputs and the alternative tool. The repeated 'FREE — FREE:' prefix is redundant and adds noise, so it does not earn a perfect score.

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

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

For a simple one-parameter tool, the description covers purpose, key return fields, and the main alternative well. However, the missing input format guidance for q is a significant gap because the agent cannot reliably construct the call without knowing whether q is a URL string, key=value pair, or JSON object.

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?

Although schema coverage is reported as 100%, the only parameter description, 'JSON or key=value input for the tool', is a generic placeholder that does not explain what q should contain. The tool description says 'URL' but never explicitly maps that to q or shows an example, so the agent still lacks the precise invocation syntax.

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 checks whether a public URL is reachable and what it is, with a specific verb and resource. It also enumerates concrete outputs (HTTP status, final URL after redirects, content type, page title), making the tool's purpose unambiguous and distinct from the sibling web_fetch.

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 explicitly routes the agent to web_fetch when full text and links are needed, which implies free_url_check is for lightweight reachability and metadata checks. This provides an explicit alternative and a clear condition, satisfying the when-to-use vs alternatives requirement.

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

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

With no annotations, the description carries the behavioral burden. It discloses the call cost, implies a read-only 'snapshot' operation, and lists exactly what data is returned. However, it doesn't state auth needs, rate limits, error behavior, or confirmation that no repository is modified.

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 with no filler: the price is upfront, the returned fields are listed compactly, and the usage case is appended. Every phrase 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?

The output fields are enumerated, which helps since there is no output schema, but the tool's sole input is opaque. Without an example or an explicit repo-identifier format, an agent cannot reliably construct a valid call, making the definition incomplete 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 only parameter q has a generic schema description ('JSON or key=value input for the tool') and the top-level description never explains how to identify the repo (owner/name, URL, etc.). Even though schema coverage is 100%, the description adds no real parameter semantics, leaving the agent to guess the input format.

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 ('GitHub repo') and enumerates the exact snapshot fields (stars, forks, open-issue count, watchers, primary language, SPDX license, dates, latest release tag), making the purpose concrete. It does not explicitly distinguish itself from the sibling repo_diligence, so it falls just short of full 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?

It gives an explicit use context: 'Use to triage a repo before contributing or depending on it.' This tells an agent when the tool is appropriate, but it offers no exclusions or alternatives such as repo_diligence, so it doesn't reach the top score.

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

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

With no annotations, the description carries the behavioral burden. It discloses the cost ($2.5 per call), which is critical for an agent to weigh invocation, and enumerates the exact outputs (last 5 commits, contributor count, etc.). It does not mention side effects or data persistence, but since this is a read-only lookup, the explicit list of outputs provides strong transparency.

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 (two sentences) and front-loads the cost and purpose. The list of outputs is efficiently crammed into one sentence. It could be slightly more compact, but every word adds value—no fluff. Good structurungal though the parameter ambiguity hurts slightly.

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 has a single parameter, no output schema, and no annotations, the description does a good job of providing context. It covers what the tool does, why to use it, and cost. Missing details about how to specify the repo (the 'q' format) and what the output structure looks like, but these are not critical for an agent to decide whether to use it. Overall, it is nearly complete for an initial decision.

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 defines only one parameter 'q' with a generic description ('JSON or key=value input'), leaving the format and intended content ambiguous. The description does not explain how to specify the repo, but given the schema coverage is 100% (though shallow), the description partially compensates by clarifying the tool's scope. The gap is that the parameter format is not detailed, but the tool's purpose is clear enough.

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 GitHub repository due-diligence and lists specific data points included (snapshot, commits, contributor count, archived flag, etc.). It uses a precise verb ('due-diligence') and resource ('GitHub repo'), and differentiates itself from siblings by focusing on repo trustworthiness, unlike e.g., github_repo or web_fetch.

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 explicitly states when to use: 'Use to decide whether to depend on or contribute to a repo before trusting it.' This gives clear context for use. It does not explicitly name alternatives or say when not to use, but the purpose is specific enough that an agent can infer it should be used for repo trust assessment, not for general repo browsing.

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 present, so the description carries the full burden. It discloses the per-call cost, the read-only eth_call mechanism, and the fields returned. However, it does not describe error behavior, rate limits, or behavior for non-token or invalid addresses.

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

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

A single, compact sentence that front-loads cost, scope, returned data, method, and intended use. Every phrase earns its place with no filler.

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

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

For a simple one-parameter, no-output-schema tool, the description covers the address target, the retrieved fields, and the use case. The only notable gap is the precise input format for q, which is left vague by both the schema and the description.

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 q parameter has only generic schema text ('JSON or key=value input'), so the description adds useful context by implying a Base token address is expected. But the exact required format—whether an address alone or an object with chain/address fields—remains undocumented. High schema coverage by count gives a baseline of 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: on-chain ERC-20 metadata (name, symbol, decimals, total supply) for a Base token via eth_call. It clearly distinguishes itself from the sibling tools, which target domains, repositories, and web pages.

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

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

Explicitly tells the agent when to use the tool: 'Use to sanity-check a Base token address before interacting with it.' It does not mention exclusions for other chains or token standards, but the 'Base ERC-20' qualifier and sibling context make the intended scope clear enough.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It discloses the cost, the URL limit (1–3), the extraction process, and the output format. It does not cover failure modes, rate limits, or how invalid URLs are handled, but it provides a reasonable baseline for a tool of this nature.

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 that front-loads the cost and purpose, then lists extraction details and output characteristics. It is concise, with no redundant phrasing, and covers the key points an agent needs to understand the tool's function.

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's complexity is moderate, but the input schema is a single opaque parameter with no guidance on format beyond 'JSON or key=value.' The description does not explain how to specify multiple URLs, what keys to use, or what the structured output looks like. Given there is no output schema, an agent would have difficulty calling this tool correctly without additional context.

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 defines a single parameter 'q' described as 'JSON or key=value input for the tool,' which is extremely vague. The description mentions the tool accepts 1–3 URLs but does not explain how to structure them within the parameter. The schema description coverage is 100% only because the parameter has a description, but that description adds almost no useful meaning, and the tool description does not compensate.

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's purpose: it creates a multi-source research brief from 1–3 URLs, extracting title, meta description, key sentences, and outbound links. It specifies the output as a structured, citable brief, which distinguishes it from a simple fetch tool like web_fetch, 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?

The description implies when to use it: when an agent needs a research brief without direct web access, and notes a cost of $3 per call. However, it does not provide explicit guidance on when not to use it or mention any alternative tools, leaving the decision partially to the agent.

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

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

With no annotations provided, the description carries the burden of disclosure. It mentions the cost, the requirement for a public URL, and the nature of the output (cleaned text, truncated, top 20 links). It does not cover error behavior, rate limits, or auth needs, but what it discloses is accurate and useful.

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 that front-loads cost and purpose, then lists output fields. It is efficient and well-ordered, with no wasted words.

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

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

For a tool with one parameter, no output schema, and no annotations, the description is incomplete. It fails to specify the input format for the URL, does not address error handling or edge cases, and omits any guidance on expected usage patterns. The agent cannot reliably call this tool based on the provided information.

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 defines a single 'q' parameter described only as 'JSON or key=value input', which is entirely generic. The description does not explain how to pass the URL or what keys/format to use. Neither the schema nor the description provides actionable parameter semantics, making correct invocation impossible without external knowledge.

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 fetches a public URL and lists the return fields (status, final URL, title, cleaned text, top 20 links). It is specific and unambiguous, though it does not explicitly differentiate from sibling tools like web_brief or free_url_check.

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 mentions a use case ('when an agent itself cannot reach the open web'), giving some context. However, it does not specify when to prefer this over alternatives or provide any exclusions or prerequisites, leaving the routing decision to inference.

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