onyx-mcp

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

With no annotations, the description carries the full burden. It discloses non-determinism (multiple runs), use of a live web-grounded answer engine, Ed25519 signing, and pricing. It does not mention rate limits, prerequisites, or failure modes, but the level of detail is high for a non-annotated 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?

The description is a single dense paragraph that covers all key aspects without redundancy. It is efficient for the information conveyed, though it could benefit from bullet points or clearer separation of ideas.

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 no output schema, the description lists most return components (score, confidence interval, weights, etc.), enabling an agent to understand the output. It addresses input parameters, process, and pricing. However, it lacks details on error handling or expected output format.

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 baseline is 3. The description adds overall context (e.g., 'category drives buyer-intent prompts') but does not provide significant additional per-parameter meaning beyond the schema descriptions. The value added is marginal.

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 explicitly states the tool computes a 'SIGNED, auditable answer-engine visibility number' for a brand/product/agent using a fixed buyer-intent prompt set. It clearly differentiates the tool from alternatives like Profound/Semrush-AI and lists specific output metrics (AEO score, confidence interval, weights, 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?

The description contrasts the tool with Profound/Semrush-AI, implying use when transparency and audibility are needed, but it does not provide explicit guidance on when to use this tool versus sibling tools (e.g., onyx_ai_visibility). No when-not-to-use or alternative recommendations are given.

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 full burden. It discloses the pricing ($0.25 USDC) and that the result is Ed25519-signed and reproducible. It does not mention destructive side effects, but the tool appears to be a read-only data retrieval. The disclosure of cost and signature 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 a single, well-formed paragraph that front-loads the core purpose. Every sentence adds value—no padding. Slightly long but all content is necessary. Could benefit from bullet points for clarity, but not required.

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 no output schema, the description fully explains what the tool returns (signed map, segments, census, reconciliation) and includes usage context, pricing, and parameter behavior. For a 1-parameter tool with no output schema, it is exceptionally 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%, baseline 3. The description adds practical guidance: explains what max_pages controls (Bazaar pages, 100 resources each), the default (300 = full sweep ~28k), and trade-off (lower for faster sampled read). This goes beyond the schema's bare description.

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 it returns a signed Agent-Economy Index with segments, live Coinbase Bazaar census, and reconciliation. It distinguishes itself from sibling tools focused on registry, verification, and payments by being the dedicated economy index tool.

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 advises using this tool 'before citing any agent-economy number in a deck, report, or decision.' This tells when to use. It lacks explicit when-not-to-use or alternatives, but the context signals and sibling names imply no other tool serves this specific purpose.

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 details the behavior: 'Ed25519-signed, timestamped, recomputable' output, two actions with different characteristics (census is fast no live calls, probe includes live hollow-detection), bounded sample (1-12), and the default registry URL. It also mentions cost ($0.05 USDC) and tier (metered). No annotations exist, so the description fully covers behavioral traits.

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 front-loaded with the key action and provides dense but efficient information. Each sentence adds value, though some minor redundancy exists (e.g., mentioning price twice). It is not overly long, balancing detail with conciseness.

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 complexity of the tool (two actions, bounded sample, registry URL), the description covers all necessary aspects: what it does, how it works, the parameters, the output (trust signals), and even pricing. No output schema is provided, but the description explains the output breakdown sufficiently.

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 has 100% description coverage for its three parameters, but the main description adds context beyond the schema. For example, it explains 'action='probe' also live-tests a bounded sample' and details what 'census' and 'probe' produce. This extra information helps the agent understand the semantic difference between parameters.

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: 'Signed verified-registry audit. Fetches a public A2A agent registry ... and re-grades it' with specific metrics. It distinguishes between 'census' and 'probe' actions, making it clear what each does. This differentiates it from sibling tools like 'onyx_agent_verify' which likely target individual agents.

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 includes an explicit use case: 'Use to vet an agent directory before trusting its listings, or to find a real agent to transact with.' While it doesn't explicitly state when not to use it or compare with siblings, the context makes the usage clear. Adding a note on when to prefer alternatives would improve 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?

With no annotations provided, the description fully carries the burden. It discloses the mechanism (two distinct challenges), outcomes, additional checks (signature, auth), and the signed verdict format. It does not mention rate limits or authentication for the tool itself, but covers the key behavioral aspects.

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 (around 100 words) and well-structured, with front-loaded purpose and no extraneous information. Every sentence adds value, including pricing and tier details.

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 only one parameter and no output schema, the description is complete: it explains input options, output types, and use case. An agent can understand when and how to invoke the tool 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%, providing a baseline of 3. The description adds extra value by specifying the types of URLs accepted (A2A endpoint, agent card URL, base origin), going 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's purpose: verifying agent liveness and authenticity via challenge messages, checking cryptographic signatures, and auth behavior. It specifies distinct outputs (ALIVE, HOLLOW, DEAD) and additional checks, and distinguishes itself from sibling Onyx 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 explicitly advises using the tool before trusting or transacting with an agent listed as healthy by a registry, providing clear context. However, it does not mention when not to use it or list alternative tools for similar tasks.

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 bears the full burden. It describes the tool as a 'signed reading' and states 'Never fabricated', implying reliability. However, it does not disclose any limitations, rate limits, error handling, or whether the output is cached or real-time, which would be beneficial 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 description is concise, consisting of two sentences plus parentheticals. It front-loads the purpose and key output details. The inclusion of price and tier is informative but slightly adds clutter; overall, it is well-structured with minimal waste.

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 no output schema, the description lists all expected output components (presence, recommendation set, sentiment, share-of-voice, cited sources, visibility score) adequately. It also explains the role of each input parameter. However, it could be more structured in describing the return format.

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% with good descriptions. The tool description adds value by providing examples (e.g., 'Onyx Protocol', 'AI agent payment rails') and explaining how the category drives the 'best <category>' query, thus adding context 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 it is an AI answer-engine visibility oracle, specifying the input (brand/product) and detailed outputs (presence, recommendation set, sentiment, share-of-voice, cited sources, visibility score). It distinguishes itself from siblings by calling it 'the new SEO' and 'one per-call x402 tool'.

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 explains what inputs are needed (brand, optional category, competitors) and what outputs are produced, but lacks explicit guidance on when to use this tool versus alternatives among the many sibling tools. It does not provide 'when not to use' or mention any prerequisites.

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 explains the cryptographic checks (Ed25519 signature, kid, tamper detection) and declares the tool as 'FREE' with price $0. It lacks details on error handling or rate limits, but covers core behavior well.

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 well-structured: starts with the verb 'Verify', explains usage, then the outcome, and ends with supplementary info (free, cross-check). Every sentence is purposeful.

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, the description fully explains what the tool does, how to use it, what results to expect, and even provides a verification tip. It is contextually 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 description reinforces the schema's parameter description and adds meaning by explaining what the verification yields (validity of signature, kid, tamper status). Since there is no output schema, this additional context is valuable.

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 verifies Onyx-signed security verdicts, including cryptographic signature verification, key identification, and tamper detection. It distinguishes from siblings by being the sole verification tool for Onyx attestations.

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 tells users to 'paste back any result from an Onyx tool' and suggests cross-checking the kid against a public key. While it doesn't state when not to use or name alternatives, the context is clear that this tool follows attestation generation.

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 thoroughly explains the tool's behavior: fetching verified source, running static vulnerability detectors (listing examples), flagging live on-chain risks, optional deep pass, output format (ALLOW/REVIEW/BLOCK + score), and signing of findings. It also discloses pricing and tier. This is highly 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?

The description is relatively long (4-5 sentences) but packs in essential information: purpose, process, features, output, and pricing. It is front-loaded with the main purpose. Every sentence adds value, though it could be slightly more concise by grouping related details.

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 the input (address, optional deep), process (static analysis, live risk flags), output (risk score and findings signed), and pricing. No output schema exists, but the description adequately explains the return format. For a complex security audit tool, this is fairly complete, though more detail on the exact structure of findings could be useful.

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 value by explaining the overall audit process but does not significantly enhance parameter semantics beyond what the schema already provides. The description for the 'deep' parameter is essentially repeated from the schema. No additional constraints or formatting details are added.

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 full smart-contract security audit for any Base address. It uses specific verbs (Fetches, runs, flags, returns) and distinguishes from siblings by focusing on audit rather than verification or other contract-related tools. The description explicitly mentions what the audit covers (static detectors, live on-chain risks, optional deep pass).

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 usage context by stating the audit is 'cheaper than a manual audit' and 'audits the contract as actually deployed.' It implies when to use this tool (for security auditing) but does not explicitly mention when not to use it or provide alternatives like onyx_base_contract_verify. However, the context is clear enough for an agent to decide.

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 full burden. It discloses the output is a signed snapshot, free tier, Ed25519-signed, and includes observed_at dating. It does not mention that the operation is read-only or non-destructive, but the nature of a snapshot implies no side effects. The price and tier are also disclosed. Minor gap: no explicit statement about auth requirements or rate limits, but overall 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?

The description is a single long sentence with many details, making it somewhat dense. It is front-loaded with the core purpose. However, it could be more concise by breaking into shorter sentences or removing redundant phrasing like 'Free tier' already stated. The key information is present but could be tightened.

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 complexity (multiple data sources, signed output, free tier) and the lack of output schema, the description covers essential aspects: what data is included, the signature, date, and pricing. It does not detail the exact output structure, but for a snapshot tool with one parameter, it is largely 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% for the single parameter 'census_limit', which is described as 'How many CDP discovery entries to sample for the census (top categories).' The main description does not add any additional meaning beyond what is already in 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 it provides a 'signed snapshot of the agentic ecosystem' with specific components (citizen counts, fact-layer, CDP census, competitor map). The verb 'observe' and resource 'ecosystem intel' are precise, and the scope distinguishes it from siblings like onyx_agent_registry or onyx_preflight.

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 'One call to understand who's live and where 0n1x sits,' implying it is for a broad overview. However, it does not explicitly state when to use or not use this tool versus alternatives, nor does it mention prerequisites or limitations. Guidance is implied but not explicitly provided.

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 burden. It discloses read-only nature (eth_call, no funds), signed output, and cost ($0.05 USDC, metered tier). It does not discuss rate limits or latency, but the main behavioral traits are covered.

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 three sentences, each serving a clear purpose: identifying the tool and its domain, listing return values and conditional behavior, and explaining the signed proof and cost. No unnecessary 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?

Given no output schema, the description adequately outlines the return values (metadata, totalSupply, identity check) and the signed nature. It could elaborate on what 'registry metadata' includes, but for a relatively simple tool with three optional parameters, this is sufficient.

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 baseline is 3. The description adds value by explaining the purpose of the optional address parameter (checking for identity NFT) and the context of the registries. It reiterates that chain defaults to Base and registry defaults to identity, aiding understanding beyond the enum descriptions.

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 it is a signed on-chain read of ERC-8004 registries, specifying the exact registries (Identity and Reputation) and the network (Base mainnet). It lists what the tool returns (registry metadata, totalSupply, optional address check) and highlights the unique signing feature. This clearly differentiates it from sibling tools like onyx_agent_registry.

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 implicit usage guidance by stating the tool produces a signed proof for agents to verify registry facts before trusting a counterparty. It does not explicitly exclude other sibling tools, but the context of signed reads and the mention of the use case give clear direction. A more explicit 'when to use vs. alternatives' would improve this.

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 full responsibility. It discloses key behaviors: responses are Ed25519-signed, contributions earn credit, votes are weighted by OnyxRank, disputes require evidence, and the tool deals only with facts and corroboration depth, never judgments. It also states the price ($0 USDC, free tier) and the requirement to authenticate for a wallet.

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 detailed yet efficient, covering all actions, prerequisites, and behavioral notes in a single paragraph. It could be slightly more structured (e.g., using bullet points) but each sentence adds value without 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?

Given the complexity (9 parameters, 5 actions) and absence of an output schema, the description adequately covers the tool's functionality, including response signing and the requirement for a wallet. It lacks details about return formats or error handling, but overall it is sufficient for an agent to invoke the tool 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 adds context about the actions (e.g., 'contribute: observation kind...') which indirectly helps understand parameters, but the schema already describes each parameter adequately. The description does not provide additional parameter-specific details beyond what is in 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 explicitly states '0n1x Intel Exchange in one tool' and lists five distinct actions (contribute, corroborate, work, pool, credit) with brief explanations, making the tool's purpose very clear. It distinguishes itself from sibling tools by focusing on a multi-action intel exchange, while siblings like onyx_merchant_fact_check or onyx_agent_verify handle other specific tasks.

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 guidance on when to use each action (e.g., 'contribute' for signed observations, 'corroborate' for independent evidence) and mentions a prerequisite ('Requires a challenge-claimed wallet for contribute/corroborate/credit'). It does not explicitly state when not to use the tool or compare to alternatives, 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?

Discloses that messages are marked read unless peek=true, and that the tool is free with price $0 USDC. No annotations provided, so description carries burden. Does not mention rate limits or error cases but adequate for a simple check 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?

Three sentences with no wasted words. Front-loaded purpose, then parameter guidance, then pricing. Highly efficient.

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 inputs, key behavior (marking read), and pricing. Lacks description of return format or pagination, but for a simple mailbox check with 4 simple params, it is nearly 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% with descriptions, but description adds meaningful context: agent_id format, peek prevents marking read, unread_only filters. Exceeds schema details.

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?

Description states 'Check your Onyx mailbox — the async messages other agents left for you.' Clearly identifies verb (check) and resource (Onyx mailbox). Distinguishes from sibling 'onyx_mail_send' which is for sending messages.

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 instructions: identify yourself using agent_id, use peek to avoid marking read, set unread_only for new messages. Does not explicitly state when not to use but context is 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 full burden. It discloses that messages are asynchronous ('waits until they check mail'), free, and require no authentication. This adds valuable context not in the schema. However, it does not mention potential limits (e.g., message size, rate limits) or idempotency, leaving some behavioral aspects implicit.

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 at 3-4 sentences, front-loading the key action and purpose. Every sentence adds value (e.g., addressing format, async nature, free status). While it could be more structured (e.g., bullet points), it is efficient and appropriate for the tool's simplicity.

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 purpose, usage, and key behavioral traits. However, with no output schema, it omits mention of the response format or error handling (e.g., what happens if the recipient doesn't exist). Given the tool has 4 parameters including nested objects, a brief note on expected outcomes would improve completeness.

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 baseline is 3. The description adds meaning beyond the schema: for 'to', it explains that names/callsigns or addresses are acceptable; for 'specs', it clarifies that structured data is preserved verbatim. This additional context elevates the score above baseline.

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 verb 'Leave an async message' and the resource 'another agent's Onyx mailbox'. It distinguishes from sibling tool onyx_mail_check by explaining that messages wait until the recipient checks mail. The addressing methods are specified, making the tool's purpose distinct and 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?

The description provides guidance on how to address recipients (name/callsign or address) and mentions that mail is checked via onyx_mail_check. However, it lacks explicit when-to-use versus when-not-to-use advice, and does not contrast with other sibling tools beyond the receipt counterpart. The guidance is present but minimal.

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 burden. It discloses that the tool probes observable reality dimensions (live, discoverable, payable, breadth, transparency), returns a signed rating, publishes exact weights, and has no fee conflict. It also mentions pricing ($0.05 USDC, metered). Adequate transparency, though failure modes are not discussed.

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 front-loaded with the core concept. Every sentence adds value: definition, input, output, process, trust rationale, and use case. 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?

Given the low complexity (one parameter, no output schema), the description fully covers what the tool does, how it works, and its return format. It is complete and sufficient for an agent to understand and invoke the tool 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% with one parameter. The description adds no significant meaning beyond the schema's description ('URL of the service/agent to rate'). It reiterates 'point it at a URL' but does not add format or restrictions. 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 defines the tool as a signed, conflict-free rating for agent/x402 services, analogous to 'Moody's for the agentic web'. It specifies the input (URL) and output (0-100 rating + A-F grade, signed), and distinguishes it from sibling tools by emphasizing transparency (publishes weights) and conflict-free nature (no settlement fee).

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 the tool: 'Use it to vet a service or counterparty before you route, integrate, or pay.' While it does not explicitly state when not to use or mention alternatives, the usage context is clear and actionable.

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 explicitly discloses that the tool provides raw observations, never asserts legitimacy or scam, and that outputs are Ed25519-signed to prove genuineness and integrity. It also mentions the cost ($0.25 USDC) and tier. With no annotations provided, the description fully carries the burden of behavioral 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 at around 125 words and front-loads the tool's purpose. It lists the output fields efficiently. However, it could be slightly shorter without losing clarity, and the structure is logical.

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 4 parameters and no output schema, the description provides a good overview of the output contents (domain registration, TLS cert, reachability, brand similarity, price deviation). It lacks details on how to verify the Ed25519 signature or exact output format, but for a pre-checkout oracle the level of detail is sufficient.

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 briefly restates the parameters ('domain, optionally the brand and expected price') but does not add significant meaning beyond what the schema already provides. The schema itself gives examples and explains parameter effects well.

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 as a 'Pre-checkout merchant fact oracle' and specifies exactly what inputs it accepts (domain, optional brand, expected price) and what outputs it returns (signed observations including domain registration age, TLS certificate age, reachability, brand similarity, price deviation). It distinguishes itself from siblings like onyx_fact_check and onyx_retail_price_check by focusing on merchant domain verification with cryptographic signatures.

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 before checkout to verify merchant facts, but it does not explicitly state when to use this tool versus alternatives. There is no guidance on when not to use it or mention of other related tools such as onyx_fact_check or onyx_retail_price_check. The context is clear but lacks exclusion criteria.

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 fully discloses behavior: returns PROCEED/REVIEW/HOLD clearance based on Ed25519-signed observation log, TLS facts, domain age, price comparison. It manages expectations by stating 'Onyx never asserts the merchant is honest' and mentions cost ($0.05 USDC, metered).

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 informative without being verbose. It front-loads the purpose and then provides details. The cost note is relevant but could be integrated. Overall, every sentence contributes meaning.

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 no output schema, the description adequately explains the return value (three clearance statuses) and the process. It covers input, behavior, and cost. However, it could briefly mention how this tool connects to payment execution tools.

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 baseline is 3. The description adds value by explaining how each parameter affects clearance (e.g., brand triggers hold for cloned storefronts, large amounts lower auto-PROCEED bar). This goes beyond the schema's bare descriptions.

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 as 'Pre-payment clearance for agents' and specifies it must be called 'BEFORE settling with a merchant over x402/AP2'. It is distinct from sibling tools like onyx_secure_payment (actual payment) and onyx_x402_receipt_verify (post-payment).

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 it ('Call this BEFORE settling') and positions it as 'The check agents run at the payment chokepoint'. It does not explicitly name alternatives or state when not to use it, but the context is clear.

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, description provides thorough behavioral details: mechanical conformance check (not a verdict), signed fact bound to request (nonce+hash, replay-proof), free tier, and price. No side effects or destructive actions mentioned; appropriate for a read-only check.

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 high information density. Front-loaded with purpose. Includes price and tier, which could be separate, but not excessive. Slightly verbose but efficient.

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 no output schema and nested parameters, description covers return value (signed fact), security binding, and verification path. Provides complete context for an agent to understand what the tool does and how to use 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 coverage is 100%, so description adds limited value beyond schema. It summarizes grant fields and action fields, and clarifies history is optional. 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?

Description clearly states the tool checks whether an agent's action stays within its grant. It lists grant components and return types (IN_SCOPE/OUT_OF_SCOPE/UNDECLARED). Distinguishes from siblings like onyx_perm_grant (which creates grants) by focusing on checking.

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?

Implied usage is clear: use to verify conformance of an action against a grant. Mentions verifying result with onyx_attestation_verify. However, no explicit when-not-to-use or alternatives beyond that.

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 provides key behavioral insights: the grant is Ed25519-notarized, portable, and attests only what was declared, not the grantor's authority. This transparency about limitations 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 highly concise, front-loading the action and then adding key context in a few sentences. Every sentence serves a purpose with no 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 complexity (13 parameters, no output schema, no annotations), the description provides sufficient context: what the grant is, how to use it, and behavioral caveats. It could mention return value, but overall complete enough for 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 high (77%), so the schema already documents most parameters. The description summarizes some fields but adds little new meaning beyond listing them. Baseline score of 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 the tool mints a signed permission grant for an agent, specifying the grant format and its purpose. It differentiates from sibling tool onyx_perm_check by describing the relationship. This is specific and 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?

The description implies usage: create the grant and then evaluate with onyx_perm_check. It provides context for the grant lifecycle but lacks explicit when-not-to-use guidance or prerequisites. Still, it clearly indicates the typical workflow.

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 provided, so the description carries full burden. It discloses the probe timeout (~8s), the checks performed (HTTP 402, price parsing, address/network validation), and the verdict format. It emphasizes sign facts with traceable flags. Price and tier are mentioned. No side effects or contradictions noted.

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 fairly long but front-loads the core purpose. Every sentence adds value, covering the probe, checks, output, and pricing. Slightly dense but well-structured.

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 complexity of the x402 protocol and safety checks, the description covers the main functionality. It describes the return value (verdict and flags) without an output schema. Minor gap: exact structure of the verdict could be clearer, but sufficient for an AI agent.

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% with descriptions for both parameters. The description adds context about the probe timeout and clamping, which reinforces the schema. It provides additional behavioral context beyond the bare 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 is a 'Preflight safety check for an x402-gated endpoint, BEFORE you pay it.' It specifies probing the URL, confirming the x402 protocol, parsing price, and returning a verdict. It distinguishes from sibling tools that handle payment or verification.

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 says 'BEFORE you pay it,' indicating when to use. It warns about decoys, dead endpoints, and price traps. It does not explicitly list alternatives, but the context is 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?

No annotations provided, so description carries full burden. Discloses data sources (OpenAlex, Semantic Scholar fallback), ranking method, return fields, and cost (0.05 USDC). Does not mention rate limits or side effects, but read-only nature is implied.

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 clear, front-loaded purpose. Every sentence adds value and there is no unnecessary 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?

The description covers most relevant aspects: data source, ranking, return fields, pricing, and use case. Lacks mention of pagination or total results, but complete enough for a search tool with detailed schema.

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 well-documented in schema. The description adds context on ranking and fallback but does not significantly enhance parameter meaning beyond what the schema provides.

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 function: 'Research intel — has someone solved X already?' It specifies querying 240M+ academic works via OpenAlex, ranking by citation count, recency, and relevance, and returning top N papers with abstracts, citations, and authors. It distinguishes itself from sibling tools like onyx_paper_synthesis.

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 states intended use: 'Built for autonomous agents that need to check prior art before burning cycles re-deriving a known result.' Provides context with a fallback mechanism and pricing. Does not explicitly state when not to use, 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 provided, so description carries full burden. It discloses key behaviors: fetches fresh data, never guesses, returns price=None with confidence='none', and provides extraction source. It also mentions cost. However, it does not cover error handling for invalid URLs, rate limits, or authentication 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 (4 sentences), well-structured: purpose, behavior, usage guidance, cost. Every sentence adds value; no 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 no output schema, the description adequately outlines result fields (price, currency, in-stock state, extraction source, matches_expected/drift). For a simple 2-param tool, this is sufficient but could be more explicit about output structure.

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 baseline 3. The description adds meaningful context beyond schema: for 'expect_price' it explains the purpose (detect stale/hallucinated quotes) and the returned fields (matches_expected, drift). For 'url' it reinforces the expected usage. This adds value.

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 real-time retail prices from product URLs, distinguishing it from siblings like onyx_bazaar_compare by emphasizing 'ground-truth retail oracle' and 'long tail of no-API shops'. The verb+resource+scope are specific and 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?

The description provides explicit usage guidance: 'Use before an agent quotes, compares, or transacts on a price it would otherwise invent.' It also explains when it returns None. However, it does not explicitly mention alternatives among siblings 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?

With no annotations, the description carries full burden. It discloses key behaviors: returns PASS/REVIEW/FAIL verdict, risk score, take-rate quote; uses Ed25519 signing; Onyx never takes custody; cost is $0.25 USDC. However, it omits idempotency, side effects, or authentication requirements, but provides good overall 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 a single paragraph that conveys necessary information but includes minor marketing fluff ('serious agent', 'full security stack') and pricing details. It is front-loaded with the purpose, but could be more concise.

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 no output schema, the description adequately explains return values (verdict, risk score, quote) and signing proof. It covers operational context (security stack, no custody, cost). Missing error handling or rate limits, but overall complete for a clearance 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%, so baseline is 3. The description adds value by explaining how optional parameters trigger additional checks (contract audit, reputation). It also clarifies that amount drives risk threshold and take-rate, which goes beyond the schema's descriptions.

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: 'Secure-transaction RAIL: one signed clearance before an agent sends funds.' It specifies the action of obtaining a security verdict for a payment, distinctively positioning itself among siblings as a pre-payment clearance check. The verb 'Give' plus inputs makes it concrete.

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 ('before moving real money') but does not explicitly state when to use or avoid this tool versus siblings like onyx_approval_guard or onyx_tx_guard. No alternatives or exclusions are mentioned, leaving the agent to infer.

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 provided, so description fully carries the burden. It discloses output nature (list of flags), signing (Ed25519), and verifiability. Does not mention read-only or safety aspects, but the context implies it's a read operation.

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?

Description is fairly long but well-structured and free of fluff. Each sentence adds value: purpose, parameters, interpretation, signing, price. Could be slightly more concise but remains effective.

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 description compensates by explaining the output type and content. Covers key aspects: input options, output nature, verification path. Missing potential error conditions or response format details, but sufficient for complex 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%, and description adds value by explaining the purpose of each parameter (endpoint for fetching, agent record for deeper scan). Provides more context than the schema alone.

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?

Description clearly states the tool returns signed security flags for an agent, listing specific examples. It distinguishes from sibling tools by focusing on offline-verifiable conditions rather than verification or scoring.

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?

Explains when to use: pass endpoint and/or agent record. Provides guidance on interpretation (facts vs judgments). Mentions verification via sibling tool. Lacks explicit when-not-to-use or alternative comparisons.

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 exist, so the description fully covers behavior: it flags unlimited permits, EOA spenders, NFT-order signatures, etc., and returns ALLOW/REVIEW/BLOCK with explanation, plus discloses pricing and tier.

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 well-organized and front-loaded with the key purpose, but contains some extra details (e.g., the #2 wallet-drain vector) that could be condensed. Still, every sentence adds value.

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 only one parameter and no output schema, the description fully explains the tool's purpose, inputs, checks performed, and output format (ALLOW/REVIEW/BLOCK + explanation), making it complete for the agent.

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 describes the typed_data parameter fully. The description adds context about what the check does but does not add new information about the parameter itself 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 it's a 'Pre-signature firewall for OFF-CHAIN drains' specifically for EIP-712 typed-data messages, distinguishing it from sibling tools that cover on-chain transactions or other checks.

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 says to use it 'before your agent signs an EIP-712 typed-data message' and lists what it checks, but does not provide explicit instructions on when not to use it or contrast with specific sibling tools.

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 fully discloses behavior. It details all risk factors provided (honeypot, buy/sell tax, mintable, ownership-reclaim, transfer-pausable, proxy, LP-lock, holder count) and the nature of output (Ed25519-signed, timestamped, risk score and verdict recomputable from factors). It also mentions pricing and tier, offering complete 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 well-structured and front-loaded with the tool's purpose. It contains multiple sentences but each adds necessary detail. Slightly longer than ideal, but the information density is high and the flow is logical.

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 lack of an output schema, the description covers the output comprehensively by listing risk factors and mentioning the signed, timestamped format. It explains how the risk score can be recomputed. It could be more specific about output format, but it is sufficient for an AI agent to understand the tool's capabilities.

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%, but the description adds value by clarifying that 'chain' accepts names or numeric IDs and defaults to 'base', and that 'contract' is a 20-byte hex address. It also explains the purpose of both parameters beyond the schema descriptions.

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 as a token-security oracle that provides on-chain risk facts. It lists specific data points (honeypot, tax, mintable, etc.) and explicitly states the use case: 'Use before any agent swaps into or quotes an ERC-20 it didn't issue.' This distinguishes it from siblings like 'onyx_base_token_risk_scan' by emphasizing signed and timestamped outputs.

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 a clear usage directive: use before swapping or quoting an unrecognized ERC-20. It implies when to use but does not explicitly mention when not to use or alternatives. However, the context of signing and recomputation differentiates it from similar tools.

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 reveals the tool is read-only, free, and public, but lacks explicit statements about idempotence, authentication needs, or rate limits. The marketing language reduces clarity on behavioral traits.

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 overly verbose with marketing fluff like 'Onyx's measured precision — the proof no other x402 security tool can show.' It could be condensed to one or two factual sentences without losing meaning.

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 one optional parameter and no output schema, the description adequately explains what it returns (signed summary, precision, miss rate, counts) and data source. It is sufficient for an agent to use the tool 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?

The single parameter 'tool' is described as optional with an example. Schema coverage is 100%. The description adds context by mentioning 'counts by tool and outcome', which explains the parameter's purpose. No further detail needed.

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 it returns a signed summary of verdict-to-outcome ledger, including block precision, miss rate, and counts. It distinguishes itself as the tool for verifying Onyx calibration, setting it apart from sibling tools that focus on individual actions or reports.

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 use when wanting to verify Onyx's calibration and notes it is free and public. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use conditions.

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 provided, so the description fully discloses behavior: it performs on-chain checks (EOA vs contract, account age, funding history, burn/null-address, sink/honeypot heuristics) and returns a signed verdict. It explicitly states 'Never guesses' and that every field is observed on-chain and Ed25519-signed.

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 moderately concise, effectively front-loading the purpose and then listing the checks. Each sentence adds value, though some redundancy exists (e.g., 'pre-payment' and 'before the money leaves'). Slight improvement possible by trimming 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?

For a tool with no output schema, the description adequately explains the return value (signed allow/review/block verdict + risk score). It also includes pricing and tier information. The tool's complexity is high, but the description covers all necessary aspects for agent 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?

The input schema already describes both parameters (address and amount_usdc) with 100% coverage. The description adds no additional semantic detail beyond the schema, only reinforcing the context of 'recipient address your agent is about to pay (Base)'.

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 as a 'Pre-payment security firewall' that provides a signed verdict and risk score for a recipient address. It distinguishes itself from sibling tools by focusing on on-chain security checks before payment.

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 context on when to use: before paying a recipient address on Base to get a signed allow/review/block verdict. It does not explicitly state when not to use or list alternatives, but the purpose is well-scoped.

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 burden. It discloses that the tool decodes the 4-byte selector and args, identifies wallet-drain patterns, and returns a verdict (ALLOW/REVIEW/BLOCK) with explanation. It also mentions pricing ($0.10 USDC) and tier (metered). It does not cover edge cases like unrecognized selectors, but overall 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?

The description is concise at ~100 words, front-loaded with the core purpose, and efficiently covers functionality, patterns flagged, and return type without 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?

Given the tool's complexity and no output schema, the description adequately explains the output (SIGNED ALLOW/REVIEW/BLOCK + human explanation). It covers the main behavior and distinguishes it from many transaction-related siblings. Minor omission: no details on explanation structure or verdict triggers.

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% with clear parameter descriptions. The description reinforces the three parameters (to, data, value_wei) in context but adds no new constraints or formatting details beyond what the schema already provides.

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 as a 'Universal pre-sign firewall' that checks transactions before signing, decodes them, and flags dangerous patterns like unlimited approve and blanket NFT approvals. It distinguishes from siblings (e.g., onyx_base_tx_decode) by emphasizing its safety focus and specific patterns detected.

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 says 'the check before your agent signs ANY transaction' and recommends every signed tx should pass through it. This provides clear context for when to use it, though it does not explicitly exclude alternative tools or describe 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?

With no annotations provided, the description fully covers behavioral aspects: it details the verification process, issuance of signed records, badge, status URL, validity period, renewal, and pricing. It also explicitly states limitations (does not claim honest/safe), ensuring 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 well-structured and front-loaded with the main action. It is slightly lengthy but every sentence adds value, explaining the process, outcome, and caveats. Could be slightly more concise but remains effective.

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?

Despite lacking an output schema, the description comprehensively explains the return values (signed record, badge, status URL) and provides context on validity, renewal, and pricing. It covers all necessary aspects for an agent to invoke the tool 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. The description adds minor context for the 'domain' parameter (examples) but does not significantly enhance meaning beyond the schema for the optional parameters 'contact' and 'agent_id'.

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: to get a domain Onyx Verified, with specific actions like running checks and issuing a signed record. It uses strong verbs and specifies the resource (domain), distinguishing it from sibling tools through unique functionality.

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 context on when to use the tool (for domain verification) and clarifies what the verification does and does not imply (neutral attestation, not honesty). However, it does not explicitly state when not to use or mention alternatives 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?

Describes behavior: decodes header, runs 10 rules, returns first failing rule with fix. Discloses stdlib-only, no network, free tier. No annotations to contradict; covers key traits.

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 without filler. Front-loaded purpose, then rules, then specific caveat. Every sentence adds value.

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 what it does, what it returns (first failing rule), and a common scenario. No output schema but return behavior implied. Adequate for a diagnostic 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%; description adds context linking parameters to rules (e.g., payment_requirements used for matching). Does not repeat schema but provides useful relational info, just above baseline.

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?

Clearly states the tool diagnoses a failing x402 v2 /verify by decoding headers and running 10 rules. Differentiates from sibling tools like onyx_x402_simulate by focusing on debugging the exact failure.

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 context on when to use (failing /verify) and highlights a common case (bare 402 from JWT/schema fail). Lacks explicit 'do not use' guidance but is clear enough for most scenarios.

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 full burden. It discloses the core behavior ('decodes the USDC Transfer log and confirms/refutes a claim'), the output format (success status, decoded values, discrepancy report), and that it's free. It doesn't mention side effects, but the tool is inherently read-only.

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 (3-4 sentences) and front-loaded with the core purpose, followed by details and use case. Every sentence adds value without 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?

The description fully covers what the tool does, how it works (decoding log, returning discrepancy report), and its output. Without an output schema, it provides enough information for an agent to understand the response format.

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 has 100% description coverage, so the description adds minimal new information beyond what the schema already provides. The schema already includes details like tolerance for expected_amount_usdc. Baseline of 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 the action ('Verify an x402 USDC settlement'), the specific resource (x402 receipt on Base/Base Sepolia), and the method (given a tx hash). It distinguishes itself from sibling x402 tools by focusing on receipt verification.

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 use cases ('agents reconciling spend and operators auditing inbound payments') and context (free tier). While it doesn't explicitly state when not to use or name alternatives, the sibling list includes other x402 tools that might be more suitable for other tasks, so inference is possible.

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 provided, so description bears full burden. States it is a public signed identity issuance, mentions deterministic callsign, and notes 'price: $0.00 USDC, tier: free'. However, lacks disclosure on behavior for duplicate addresses, error handling, or idempotency.

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?

Description is front-loaded with core purpose, followed by details and pricing. Four concise sentences efficiently convey the tool's function and constraints without 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?

No output schema exists, but the description adequately explains the return value (signed identity with callsign, did:pkh, credential). Price and tier are included. For a simple single-parameter tool, context is sufficient.

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 'address' parameter. The description reinforces the parameter's role ('give a self-custody Base address') but does not add new semantic information beyond what the schema already provides.

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?

Description clearly states the tool's action: taking an EVM address and returning a signed identity with deterministic callsign, did:pkh, and verified credential. Distinguishes itself from siblings like 'rhinogent_mandate' by calling itself 'the front door of the agent identity wallet'.

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 specifies the input (self-custody Base/EVM address) and the output (signed identity). Implicitly suggests use when needing a verifiable on-chain identity, but does not explicitly state when not to use or list alternative tools. Provides context that keys never leave 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?

No annotations are provided, so the description must disclose behavior. It states the outcome (signed PERM_v0 grant) and includes price/tier, but does not detail side effects, permissions needed, or whether the action is reversible. More behavioral context (e.g., on-chain vs off-chain) would be beneficial.

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 very concise: two sentences plus a tagline and price/tier. It front-loads the main action and key features. The tagline is slightly redundant but harmless. The price/tier info is useful but could be separated.

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 10 parameters, no output schema, and no annotations, the description explains the purpose and constraints well but lacks details on the return format (e.g., what the signed grant looks like) and prerequisites (e.g., agent must exist). It covers the main concept but leaves gaps.

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 baseline is 3. The description adds value by summarizing parameters into categories (e.g., 'rolling-window USDC caps' for daily_cap_usdc and spend_max_usdc, 'merchant/domain allowlists' for allowed_merchants/allowed_domains), providing a higher-level understanding beyond individual schema descriptions.

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 ('Author a signed spend mandate') and clearly identifies the resource (mandate for an agent). It lists key constraints like caps, allowlists, velocity, and expiry, distinguishing it from sibling tools like onyx_perm_grant or rhinogent_identity.

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 (define spending boundaries for an agent) but does not explicitly state when to use this tool versus alternatives or provide exclusions. The tagline 'Transacts autonomously, within the boundaries you define' gives context but lacks direct comparison to 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?

With no annotations provided, the description should fully disclose behavior. It correctly states the tool returns 'facts only (never 'legit/scam')' and mentions signed output, but does not discuss authentication requirements, rate limits, or any potential side effects, leaving some behavioral gaps.

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 extremely concise, with two sentences that front-load the core purpose and list key facts. Every phrase adds value, including the pricing note, with no redundant or verbose language.

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 absence of an output schema, the description adequately explains what the tool returns (a set of signed facts) and covers all three parameters. It could further elaborate on return format or interpretation, but the current level is sufficient for an agent to decide to call 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 descriptions cover 100% of parameters, so the baseline is 3. The description reinforces the meaning of 'brand' and 'expected_price' by linking them to observations (impersonation-similarity and price deviation), but adds no additional semantic information 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 defines the tool as providing Ed25519-signed raw facts about a counterparty before payment. It lists specific observations (domain registration age, TLS cert, reachability, etc.) and distinguishes itself by stating it's a check other wallets skip, differentiating from sibling tools like onyx_merchant_fact_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 explicitly states to use this tool 'before your agent pays a merchant,' providing clear when-to-use context. However, it omits when-not-to-use guidance or explicit alternatives, relying on the implied uniqueness.

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