402oracle

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, and it delivers: it discloses that the free tier returns unsigned, rate-limited results, that the paid tier yields a signed attestation with no daily limit, and that output is a signed 0-100 trust score with evidence URLs. It also surfaces the payment-header mechanism and transport equivalence. It could add failure semantics for unverifiable domains, but the disclosure is unusually thorough for a tool with zero annotation support.

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

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

The purpose is front-loaded in the first sentence, which is excellent, but the description runs long with dense commercial detail — batch pricing thresholds, x402 header format variants (PAYMENT-SIGNATURE v2 vs X-PAYMENT v1), USDC amounts, and transport equivalence. Much of this is actionable for invocation but is more than an agent needs to decide whether to call the tool, and some is inessential overhead for selection.

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 of moderate complexity with a trivial one-parameter schema and no output schema, the description is unusually complete: it covers invocation, return shape (signed attestation, trust score 0-100, evidence URLs), free vs paid auth paths, rate-limit behavior, and the batch alternative. The only gap relative to siblings is the absence of explicit disambiguation against verify_claim/verify_freshness/verify_price, but 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% and there is only one parameter (domain), which the schema already documents clearly with an example. The description adds behavioral context about what happens to the domain (RDAP, DNS, SPF/DMARC, HTTPS checks) but no additional format or constraint details beyond the schema's 'example.com'. With full coverage, 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 opens with a specific verb and resource ('Verify a business or domain is real and established') plus concrete trigger scenarios ('pays an invoice, onboards a vendor, or trusts it'). The verification methods are enumerated (RDAP age, DNS, email posture, HTTPS), which clearly distinguishes it from siblings like verify_claim, verify_freshness, and verify_price — those are all different verification facets, so an agent can tell this apart 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 states when to use the tool (before paying invoices, vendor onboarding, fraud/KYB checks) and explicitly routes multi-domain workloads to the batch endpoint with a cost comparison ('cheaper from four domains up'). It also delineates free vs paid tiers by signing and rate-limit needs. It lacks an explicit 'use verify_claim instead when...' exclusion against its siblings, but the use-case context is strong enough to guide 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?

With no annotations provided, the description carries the full burden and discloses the verdict types, confidence score, citations, signed/unsigned tiers, rate-limiting, and payment mechanics. The only slight imprecision is saying the result comes 'as a signed attestation' when the free tier is explicitly described as unsigned, but the following sentence clarifies.

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 tightly written: the core verb and resource appear in the first sentence, and every subsequent sentence adds necessary pricing, transport, or output context. There is no filler or restatement of the tool name.

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

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

For a single-parameter tool with no annotations and no output schema, this description covers the key things an agent needs: what inputs to use, what output to expect, whether it is safe/read-only, and when telemetry or payment are required. The only minor caveat is the signed/unsigned confusion, but the detailed caveats make the behavior actionable in all common scenarios.

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 'claim' parameter is already documented as 'A single factual claim, 8-600 characters.' The description reinforces that the input should be a factual claim and connects it to fact-checking behavior, but it does not add substantial parameter-level meaning 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 names a specific verb ('fact-check'), a specific resource ('a single factual claim'), and the method ('against web evidence'), so an agent can immediately distinguish this from sibling verification tools. The 'claim' scope also differentiates it clearly from verify_business, verify_freshness, and verify_price.

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 says when to use it — 'before your agent relies on it' — and explains the context of being a hallucination guard. It does not explicitly state which sibling to prefer for non-claim verification tasks, but the claim-oriented framing implies the boundary.

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 an excellent job: it discloses rate limiting, unsigned vs. signed attestations, required payment headers for signing, and the fact that the same tool call can be upgraded. It also enumerates the returned data, giving an agent a solid behavioral model beyond the schema.

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 for the amount of behavior it conveys. It front-loads the core purpose, then lists concrete return values, then adds rate-limit/payment details. Every sentence pulls weight and even the nested payment/transport details are clearly scoped to when you need a signed attestation.

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 there is no output schema, the description compensates by listing the relevant return data (HTTP status, Last-Modified/ETag, SHA-256, change flag, attestation). It also covers the key operational context: free tier limitations, rate limits, and pricing. The sibling tools are obviously different in scope, so little about invocation 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?

The schema already covers both parameters at 100%, and the description adds value by explaining how prior_hash is used ('whether the content changed versus a prior hash') and connecting the URL to HTTP status/ETag/Last-Modified. This goes beyond the schema's terse field descriptions and reinforces the mechanics of the comparison.

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 uses a specific verb+resource: 'Check that a URL is live and its data is fresh before your agent acts on its contents.' It names concrete outputs (HTTP status, Last-Modified/ETag, content SHA-256) and frames the tool as a 'freshness oracle,' which clearly sets it apart from the sibling verification tools focused on business, claims, and prices.

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 clear usage context: use this tool to verify URL liveness/freshness before acting on content. It also mentions an alternative and equal path (POST /verify/freshness over HTTP) and the condition for the paid tier. It does not explicitly say 'use verify_business/claim/price for those domains,' but the domain-specific wording makes the intended use unmistakable.

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 full responsibility for behavioral disclosure, and it does so thoroughly. It reveals the oracle mechanism, exchange sources, median cross-checking, divergence flags, signed attestation output, unsigned free tier behavior, rate-limiting, and payment-based upgrade path. This is exceptionally transparent for a tool with no annotations.

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 tool description is clear and front-loaded, with the core purpose in the first sentence. It is somewhat long because it covers the free tier, signing, payment headers, and alternate transport, but nearly every sentence conveys necessary operational context. Slight trimming could improve, but it is not bloated.

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 and no annotations, this description is unusually complete. It tells the agent what the tool returns (signed attestation), how to use it, what restrictions apply, how to upgrade to signed mode, and how the free tier behaves. Nothing critical is missing for correct selection and 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?

Schema description coverage is 100%, so the parameter is already well documented as a ticker symbol such as BTC, ETH, SOL. The description supports this without adding new parameter-specific semantics beyond sample tickers and usage context. That matches the baseline for full 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 names a specific action (verify/confirm price), a clear resource (a crypto asset price), and a distinctive capability (signed price oracle from multiple exchanges). It clearly differs from the verification siblings, which are about business, claims, and freshness rather than price.

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 explicitly frames when to invoke the tool: before the agent trades, quotes, or settles on a price. It also gives concrete usage alternatives such as adding an x402 payment header or using POST /verify/price over HTTP, but it does not explicitly say when not to use it or contrast with the sibling tools.

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