onyx-mcp

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

With no annotations, the description carries full burden. It states it scans events (read-only) and returns specific data. However, it does not disclose limitations like historical depth, pagination, rate limits, or whether authentication is required. The 'Free tier' note adds context but omits behavioral details.

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

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

The description is very concise with two sentences: the first covers purpose and return data, the second adds price/tier info. No redundant words, and it's front-loaded with the essential action.

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

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

Given no output schema and no annotations, the description is fairly complete: it lists all return fields (volume, count, top recipients, histogram, ticket size) and covers key parameters. Missing details like pagination or historical range, but acceptable for a simple tracker.

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 reinforces the parameter meanings (wallet address, direction enum, include_sepolia) but does not add new 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?

The description clearly states it's a USDC spend tracker per wallet, scanning Transfer events on Base and Sepolia, and lists the specific return data (total volume, settlement count, top recipients, etc.). This distinguishes it from sibling tools that focus on token risk, transaction decoding, 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 implies usage by stating 'Given a wallet address and direction', but lacks explicit guidance on when to use this tool versus alternatives like onyx_base_token_risk_scan or onyx_solana_wallet_activity. No when-not or alternative tool references are 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, the description carries full burden. It clearly states the tool is 'pure read' and free (no cost), implying no side effects or mutations. The description is honest and sufficient for an agent to understand its safety.

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, no filler, and front-loaded with the main action. Every word serves a purpose.

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

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

Despite no output schema, the description lists exactly what the reputation card contains. It covers purpose, usage, safety, and return content adequately. Could mention error handling or edge cases, but overall complete for a read-only 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 parameters are well-documented in the schema. The description adds minor value by noting that network_hint 'speeds lookup' and is not required, but does not significantly enhance understanding 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?

Description uses specific verbs ('Look up') and clearly identifies the resource ('agent (EVM wallet)') and the output ('reputation card' with listed details). It distinguishes itself from siblings like onyx_agent_workflow, which likely involves a different action.

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 the tool is useful for decisions on trust, discounts, or rate-limiting, and labels it as a free, pure read operation. This provides clear context for when to use it, though it does not mention alternatives or when not to use it relative 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?

Discloses key behaviors: stops on first error, returns partial results, cheaper than separate calls. No annotations provided, so description carries full burden and does 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?

Single paragraph, no fluff, front-loaded with purpose and key behavior. Could be slightly more structured (e.g., bullet for reference syntax), 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?

Explains behavior well despite no output schema: atomicity, error handling, cost. Covers typical concerns for a workflow tool. Leaves some details to schema (step constraints), but 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?

Adds significant meaning beyond the input schema: explains the inner structure of steps (tool, args) and crucial reference syntax ($ref, $prev). Schema coverage is 100%, but description enriches it.

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 it runs a multi-step workflow across Onyx tools in one paid call. Gives an explicit example chain and distinguishes from individual sibling tools.

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

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

Describes when to use (when chain known in advance) and the benefit (lower cost, atomicity). Implicitly tells when not to use (if dynamic decisions needed), though no explicit exclusion.

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 data source (Chainalysis oracle), return fields (sanctions hit, risk score, verdict, risk factors), performance (sub-second latency), and pricing ($0.25). It does not cover error handling or rate limits, but for a read-only screen, this is adequate.

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 (5 sentences) and front-loaded: first sentence states purpose, then lists returns, use cases, performance, and pricing. 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?

For a simple 2-parameter tool with no output schema, the description covers purpose, return fields, use cases, performance, and pricing. It lacks error handling details but is otherwise sufficient for an agent to invoke 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 clear descriptions for both parameters (chain and address). The description adds context about risk-factor heuristics but does not meaningfully extend parameter understanding beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states it performs 'KYC/AML sanctions + risk screen for any EVM address', specifying the action (screen) and resource (EVM address). It distinguishes from siblings like token risk scans by explicitly targeting address-level compliance.

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 identifies target users (Payment Stablecoin Issuers, agent-payment platforms) and regulatory context (GENIUS Act, July 2026), providing clear usage context. However, it does not explicitly state when not to use or list alternatives, though no sibling tool offers similar functionality.

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, but the description details the checks performed (ownership, mint, concentration, age, honeypot via eth_call, risk score). It also mentions price and tier. Some limitations (e.g., only Base ERC-20) are implied but not exhaustive.

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 dense paragraph containing multiple pieces of information. While not overly verbose, it could be structured more concisely (e.g., bullet points) for faster agent parsing.

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 no output schema, the description adequately lists return values (ownership, mint, concentration, age, honeypot, risk score). It covers the tool's purpose and major capabilities, though exact output format is unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description of the 'address' parameter (0x-prefixed, ERC-20, Base). The description adds no further parameter-specific details beyond the schema, so baseline 3 applies.

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

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

The description clearly states it risk-scans any ERC-20 token on Base mainnet, listing specific checks (ownership, mint, holder concentration, contract age, honeypot, risk score). It is distinct from all sibling tools, none of which perform risk scanning.

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 use 'before a trading agent buys a freshly minted token' and mentions it saves losses. No explicit when-not-to-use or alternative tools, but the context is clear and the tool stands alone 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?

No annotations are provided, so the description fully covers behavioral traits: it reads from Base's public RPC (no key needed), mentions demo mode returns synthetic record, and discloses pricing tier. This is comprehensive for a read-only 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 two sentences plus a brief note on demo and pricing. It is front-loaded with the core purpose, efficient with no wasted words.

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

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

Given the simple input (single hash), no output schema, and no annotations, the description fully explains what the tool returns (human-readable summary with list of fields) and additional context (RPC source, demo mode, pricing). It is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has one parameter with a description '0x-prefixed Base tx hash,' and the description text mentions 'tx_hash' but adds no new semantics. Schema coverage is 100%, so baseline 3 is appropriate.

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

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

The description clearly states the tool fetches a Base mainnet transaction and returns a human-readable summary with specific fields (from/to, value, gas, status, etc.). It distinguishes itself from siblings by noting it pairs with onyx_token_metadata for full context.

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 'Use when a trading agent needs to inspect a tx before or after settlement' and mentions pairing with onyx_token_metadata, providing clear context. It lacks explicit when-not-to-use but 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, so description carries full burden. It discloses behavioral traits: returns plain-English summary, token events, balance changes, function signature, gas, fee, status. Also notes price and tier. No contradictions.

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

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

Description is four sentences, front-loaded with core purpose, then enumerates outputs, use cases, and a comparison. Each sentence is informative, though slightly verbose; still concise overall.

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, description thoroughly covers input, return types, and use cases. It explains all relevant aspects for an agent to decide 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?

Single parameter tx_hash with schema coverage 100%. Description adds context 'Base mainnet transaction' and indicates what output to expect, but does not add significant semantics beyond 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?

Description clearly states it decodes a Base mainnet transaction into a human-readable summary, listing specific outputs like ERC-20 transfers, function selector, gas, and status. It distinguishes from sibling tools by focusing on human-readable explanation versus raw decoding.

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 explicit use cases: verifying transactions for trading agents and explaining transactions to users. Does not mention when not to use or differentiate from onyx_base_tx_decode, 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 provided, the description fully discloses that the tool is read-only and never submits a transaction. It also details the return values (success prediction, revert reason, decoded data, estimated gas) and mentions pricing, ensuring full 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?

Two sentences front-load the purpose, returns, and usage context, followed by a comparison and pricing note. Every sentence adds value, with no redundancy or fluff.

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

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

Given the tool has 5 parameters, no output schema, and no annotations, the description covers purpose, return values, usage guidance, and safety (read-only). It is complete and leaves no major gaps for an agent to understand what the tool does and when to use it.

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?

Input schema coverage is 100%, so baseline is 3. The description does not add specific parameter meanings beyond the schema, but it does explain overall behavior and return types. No additional parameter-level elaboration is provided.

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 simulates a Base mainnet transaction before sending, specifies it returns success/revert prediction, revert reason, decoded return data, and estimated gas, and distinguishes it as a pre-flight check for trading agents, comparing it to a Solana counterpart.

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 the tool before signing to avoid paying gas on failed transactions, providing clear context for when to use it. Does not explicitly mention when not to use or alternatives, but the guidance is strong.

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

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

With no annotations, the description carries the full burden. It discloses reading from Coinbase Bazaar via a public mirror refreshed every 15 minutes and notes it's free. No destructive behaviors are expected, and the description provides sufficient transparency for a read-only comparison 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 concise, using two sentences to convey purpose, usage, and data source. It is front-loaded with the core function and free of 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?

The description covers inputs, data source, refresh rate, and pricing. It does not explicitly describe the output format, but the phrase 'side-by-side comparison' and 'cheapest/most-used picks' implies a list. Given no output schema, a mention of output would increase 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 75% with descriptions for query, network, and sort_by. The description adds examples for keywords (e.g., 'captcha') and clarifies the sorting options, going beyond the schema's enum values.

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 does a side-by-side comparison of paid agent tools in the x402 ecosystem, with filtering and sorting capabilities. It distinguishes itself from sibling tools which are unrelated to bazaar comparison.

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 filtering by keyword, network, and sorting by price/volume/payers, with examples. It implies this is the tool for comparing tools but doesn't explicitly state when not to use it or mention alternatives.

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 must fully convey behavior. It mentions 'Free tier' and price, and states it does not force-submit, implying no destructive action. It could be more explicit about being read-only, but overall it adequately describes the tool's non-destructive, informational nature.

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

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

The description is concise, containing only essential information. It front-loads the purpose, then details the inspection targets, output, and pricing. Every sentence adds value, and there is no 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 simple input (one string) and no output schema, the description is complete enough. It explains input, output type (structured checklist), and behavioral nuance. Minor gaps like error handling or response format details are acceptable for a diagnostic tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, server_url, has a schema description that already explains it. The tool description adds context about the tool's purpose but does not provide additional syntactic or semantic guidance for the parameter beyond what the schema offers. With 100% schema coverage, baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Indexability audit for any x402 service.' It specifies the resources inspected (openapi.json, .well-known/x402.json, /manifest) and the output (structured checklist). This distinguishes it from siblings like onyx_bazaar_compare by focusing on audit vs. comparison.

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 clarifies that the tool is poll-based and 'doesn't force-submit', indicating it's for diagnostic use. However, it does not explicitly list alternative tools or scenarios where one might use this over others, but the context of 'audit' vs. 'compare' is implied.

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 substring matching, visibility preference, return data (match status, text, href), and demo mode behavior. Lacks details on scroll/waits/state modification, but sufficient for a simple click. No annotations to contradict.

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 plus a pricing note; every sentence carries essential information. Front-loaded with the core action and matching strategy.

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 all necessary behavioral aspects: what it clicks, matching rule, return values, and demo mode. No output schema needed; description fully equips an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has one parameter with a basic description. The tool description adds matching semantics (case-insensitive substring, visible elements) beyond the schema, enriching parameter understanding.

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 clicks the first visible button or link matching a query via case-insensitive substring match. Distinguishes itself from sibling browser tools by being the dedicated click action.

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 recommends using after onyx_browser_extract, providing clear context for when to invoke. No when-not-to-use guidance, but the single parameter and sibling set make it unambiguous.

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, so description handles behavioral disclosure. It explains it returns by value and notes demo mode echoes expression length. However, doesn't warn that evaluation can cause side effects (e.g., DOM mutation), which is a minor gap for a power 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?

Two sentences, no wasted words. First sentence states core purpose, second provides usage guidance and additional info (demo mode, pricing). Well front-loaded.

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, but description mentions return 'by value'. Lacks details on error handling, return type structure, or limitations. However, for a power tool with good usage guidance, it's largely adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage of both parameters. The description adds 'Last value is returned' for expression, which is already in the schema description. No extra context for await_promise. Baseline 3 is appropriate as schema already provides meaning.

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 it evaluates JavaScript on a Chrome page and returns the result by value. Also positions it as a power-tool for cases where simpler tools (click/extract/type) don't fit, distinguishing it from siblings.

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

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

Explicitly tells when to use: when specific tools don't fit, with examples like nested DOM, synthetic events, computed styles. Also mentions demo mode behavior. This provides clear context for selection.

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

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

No annotations, so description carries full burden. It discloses read-only nature, structured output, cheap/deterministic behavior, and demo mode behavior. Lacks rate limit or loading state info but sufficient.

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?

Single paragraph, each sentence adds value. Starts with action, details, usage, extra info. No wasted words.

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

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

For a tool with one parameter and no output schema, description covers return content (text + clickable elements with attributes), usage context, and demo mode. Missing explicit output format but is specific enough.

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 a single parameter. Description does not add meaning beyond the schema's own description. 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 it reads the page and returns visible text plus structured clickable elements. Distinguishes from sibling browser tools like click, navigate, screenshot.

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 says 'Use when an agent needs to plan its next action' and contrasts with screenshot+vision-modeling. Could be clearer on when not to use, but provides strong context.

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

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

With no annotations provided, the description carries the full burden of disclosure. It explains demo mode (returns synthetic results) vs. real navigation, pricing, and that the tool returns data after redirects. However, it does not mention error handling or timeout behaviors.

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 with zero waste: first sentence states action and returns, second sentence positions the tool in the workflow, third sentence covers demo/self-hosted and pricing. It is front-loaded and 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 the tool's complexity (browser navigation) and the lack of output schema and annotations, the description adequately covers what to expect after navigation (final URL, title, time), demo mode limitations, and pricing. It does not detail error scenarios but is reasonably complete for a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers both parameters (url and wait_seconds) with descriptions. The description adds context beyond the schema by explaining that wait_seconds is a settle time, how the url is used, and that results may be synthetic in demo mode, providing meaningful additional semantics.

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 it navigates a CDP session to a URL and waits for load, returning final URL, page title, and elapsed wait time. It distinguishes itself from sibling tools like onyx_browser_click by positioning itself as the first step of a browser-agent workflow.

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 clearly indicates when to use the tool: as the first step of a browser-agent workflow, with sibling tools acting on the resulting page. It also provides context about demo mode vs. self-hosted real navigation, though it does not explicitly state 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?

No annotations provided, so description carries full burden. Discloses return contents (title, URL, viewport), file size cap (1MB), demo mode behavior (synthetic 1×1 PNG), and pricing. Lacks details on error handling but sufficient for most use.

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?

Efficiently packs purpose, use cases, return info, constraints, and pricing into a few sentences. Front-loaded with core action. 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?

No output schema, but description lists return fields (title, URL, viewport) and the 1MB cap. Covers essential context for a screenshot tool. Missing only minor details like error scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 2 params with 50% description coverage. Description mentions 'PNG' (default format) but does not clarify the JPEG option or the format parameter in detail. Adds little beyond schema for full_page (already described in schema). Averages to baseline 3.

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

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

Clearly states 'Capture a PNG screenshot of the current CDP-controlled Chrome page and return it as base64', specifying the verb (capture), resource (screenshot), and format. Distinguishes from sibling browser tools like navigate, click, type, 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?

Provides explicit use cases: 'Use to feed a vision-LLM... or to archive an action's visual result'. Also gives context on demo vs real capture with ONYX_CDP_URL. Does not list when not to use, but sibling tools cover different actions.

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 React-safe setter, event firing for frameworks, return values (field selector and final value), and demo mode behavior. It does not cover potential error states or edge cases like missing fields, but is otherwise 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 (3-4 sentences) with no wasted words. It front-loads the core action and immediately follows with usage context and return information. 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?

The description adequately covers what the tool does, when to use it, and what it returns. It lacks information about error handling or behavior when the element is not found, but given the well-covered parameters and clear purpose, it is mostly complete for a form-filling 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%. The description adds value by explaining that 'selector' can be a name, id (#foo), CSS selector, or visible label substring, which goes beyond the schema's concise descriptions. It also clarifies that 'value' is the text to enter.

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 and specifically states the tool's purpose: finding an input/textarea/select by name, id, or visible label, setting its value via a React-safe native setter, and firing input+change events. It distinguishes itself from siblings like onyx_browser_click and onyx_browser_navigate.

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 'Use after onyx_browser_navigate when an agent fills a form,' providing clear context for when to use it. It lacks exclusion criteria or alternatives but offers actionable guidance.

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

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

With no annotations provided, the description carries the burden. It explains the tool returns IPv4, IPv6, canonical hostname, and resolution time, and notes the resolver behavior (stdlib, typical latency 20-100ms) and pricing. This is adequate for a simple lookup tool, though it could mention error responses.

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 two sentences plus a short pricing note, with no redundant information. Every sentence adds value, making it highly efficient for an agent to parse.

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

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

Given the tool's simplicity and lack of output schema, the description covers return values, performance, and pricing. It doesn't discuss error handling or rate limits, but for a basic DNS lookup this is sufficient and leaves little ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema describes the 'host' parameter as 'Domain or IP address'. The description adds value by explaining that domains yield A/AAAA records and IPs yield reverse resolution. Schema coverage is 100%, so the description enhances understanding 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 explicitly states the tool resolves domains to A/AAAA records and reverse-resolves IPs. It lists specific use cases (validating domains, checking infrastructure, CDN mapping, safety lookups), clearly distinguishing it from sibling tools like email validation or IP geolocation.

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 scenarios for when to use the tool (e.g., before scraping, infrastructure checks, safety lookups). While it doesn't explicitly state when not to use it, the context is sufficient for an agent to understand appropriate use cases.

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, but the description discloses the three validation steps, return of confidence verdict and signals, typical latency (30-80ms), and cost. Lacks error handling details but is transparent for a simple validation 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?

Two sentences with clear front-loading of purpose, followed by details on use cases, performance, and cost. No redundant information.

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

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

For a simple tool with one parameter and no output schema, the description covers purpose, checks, use cases, performance, cost, and return type. Fully adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one parameter with a minimal description. The tool description adds meaning by explaining what validation entails (syntax, DNS, disposable checks), which is not evident from 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?

The description clearly states the tool validates an email address with three specific checks (syntax, DNS, disposable), and lists use cases and output. It distinguishes from sibling tools which perform different utilities.

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 recommends using before mailing list signups, password-reset flows, or sales-lead capture. Does not mention when not to use or alternatives, but 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?

Discloses the API source (public ensideas API), no key/rate-limit issues, typical latency (200-500ms), and cost ($0.0008 USDC). Since no annotations are present, this carries the burden 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?

Four sentences, each with purpose: action, output, usage context, and operational details. No redundancy or 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?

For a tool with one parameter and no output schema, the description fully covers what it does, when to use it, what it returns, and performance/cost, making it complete and actionable for an 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?

Single parameter 'name' is fully described in schema; description adds meaning by stating it resolves to Ethereum mainnet address and returns avatar URL and resolver contract, enriching 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 resolves ENS names to Ethereum addresses (and vice versa), lists return fields (address, avatar, resolver), and distinguishes it from sibling tools that focus on URLs, DNS, or other utilities.

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 suggests using it when the agent encounters a human-readable name like 'vitalik.eth' and needs to send funds or validate identity, providing clear context. Could add when not to use, but the guidance is sufficient.

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

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

No annotations are provided, so the description must convey behavioral traits. It describes the tool as a non-destructive probe (up/down, latency, capabilities) and mentions 'Free tier', but does not disclose potential side effects, authentication needs, or rate limits. The transparency is adequate but not exhaustive.

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: it front-loads the primary action, lists facilitators, describes returns, provides usage guidance, and notes the cost. Every sentence adds value with no 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 simplicity (health check with 2 parameters) and no output schema, the description adequately covers what the tool does and what it returns (status, latency, capabilities, health score). It also includes usage context, making it sufficiently complete for an 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?

Both parameters (timeout_seconds and include_capabilities) are fully described in the input schema with 100% coverage. The description adds no significant meaning beyond the schema, only mentioning 'capabilities probe' which is already implied. 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 it is a live up/down and latency probe for all 5 known x402 facilitators, lists the facilitators explicitly, and specifies the return values (per-facilitator status, response time, capabilities probe, ecosystem health score). This distinguishes it from sibling tools like onyx_x402_facilitators.

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 advises agents not to hardcode a single facilitator and to use this tool to pick a live one, providing clear context for when to use it. It does not explicitly state when not to use or list alternative tools, but the guidance 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?

Since no annotations are provided, the description fully discloses behavioral traits: real-time web evidence fetching, return of supporting and contradicting sources, a 0-100 confidence score, and a summary. It also reveals pricing ($0.05 USDC, tier premium) and performance characteristics (sub-second latency). No contradictions exist.

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

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

The description is compact at four sentences, each adding essential information. It front-loads the core function and output, then lists use cases, then performance/pricing. 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?

Despite lacking an output schema, the description adequately specifies return values (sources, confidence score, summary). It also covers performance, pricing, and origin (Coinbase PROJECT-IDEAS.md), providing a complete picture for an agent to decide whether and how to invoke this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 100%, so baseline is 3. The description adds value by providing concrete examples for the 'claim' parameter (e.g., 'The 2026 G20 summit will be hosted in Cape Town') and clarifying the default for 'max_sources' (8). This context goes beyond the schema's descriptions, making parameter usage clearer.

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 primary function: 'Fact-check any claim by fetching real-time web evidence.' It lists specific outputs (supporting sources, contradicting sources, confidence score, summary) and concrete use cases (prediction-market resolvers, news-fact agents). The tool is clearly distinguished from its siblings, which include browser automation and URL utilities, none of which offer fact-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?

The description provides explicit use cases: 'Use for prediction-market resolvers, news-fact agents, journalist-bot pipelines, or any agent that needs to verify a statement before acting on it.' It also mentions sub-second latency and no API key requirement, aiding deployment decisions. However, it does not explicitly state when not to use the tool, which would further improve guidance.

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

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

No annotations provided; description compensates by stating external API (open.er-api.com), estimated latency (150-400ms), demo mode behavior, and price. It is a read-only conversion, so no destructive actions to note.

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 well-structured with purpose first, then use cases, then technical details. Could trim demo mode and price, but overall 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?

No output schema, but description explains return values (rate, converted amount, timestamp). Covers key behaviors given no annotations, though latency and demo mode are extraneous.

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 67% with 'from' and 'to' described; 'amount' has default but no description. Description adds that currencies are ISO-4217 and mentions specific codes, but does not add detail beyond schema for 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?

Description clearly states it converts between fiat currencies, lists specific examples (USD, EUR, etc.), and mentions returned data (rate, converted amount, timestamp). It is distinct from sibling tools with its domain (currency conversion).

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?

Describes when to use: pricing services, normalizing invoices, converting x402 USDC. Includes demo mode for testing. Lacks explicit when-not-to-use or alternative tools, but 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?

No annotations; description discloses it runs locally, never logs input, takes <2ms, and includes pricing/tier. Sufficient transparency for a pure computation 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?

Two efficient sentences: action first, then use cases and properties. No redundancy, front-loaded with key info.

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, outputs (hex/base64), behavior (local/no logging), performance, and use cases. Complete for a hash function tool despite no output 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 covers both parameters (100%), description adds output format detail but doesn't significantly extend beyond 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?

Clearly states it computes multiple hash algorithms (md5, sha1, sha256, sha512, sha3-256) for text or base64 bytes, returning each as hex and base64. Distinct from diverse siblings.

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?

Lists specific use cases (content-addressed lookups, dedupe keys, signature verification, fingerprinting). Mentions local execution and speed. No explicit exclusions but 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?

No annotations provided, so the description carries full burden. It mentions stripping HTML noise and typical latency (150-500ms), plus pricing info. It does not detail error handling or auth requirements, but for a simple fetch-and-extract tool the behavior is well conveyed.

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

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

The description is compact yet comprehensive—one sentence for what it does, one for when to use, and one for performance/pricing. No fluff, each 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?

For a simple tool with one parameter and no output schema, the description covers extraction details, use cases, and performance. It does not specify the return format (likely JSON), but the context signals suggest no output schema, so the description is reasonably 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 the single parameter 'url' already described as 'URL to inspect'. The description adds no extra semantics beyond what the schema provides, meeting the baseline 3.

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

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

The description explicitly states the tool fetches a URL and extracts OpenGraph, Twitter Card, and standard meta tags, with concrete use cases like link previewing and spam detection. It clearly differentiates from siblings by specifying the meta extraction scope.

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 gives clear use cases (previewing, citation, spam detection) but does not explicitly state when not to use it or mention alternatives among sibling tools, though the context signals show many similar URL-related 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?

With no annotations, the description fully carries the burden of transparency. It discloses the backend (ip-api.com), rate limits (~1k requests/min), typical latency (~80-200ms), demo mode behavior, and pricing ($0.0008 USDC). This provides comprehensive behavioral context for an agent.

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

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

The description is compact and upfront about the main function, then covers use cases, backend details, demo mode, and pricing. While it could be slightly more structured (e.g., bullet points), it efficiently conveys all necessary information without 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 the tool has one parameter and no output schema, the description covers all relevant aspects: purpose, usage context, behavioral details (rate limits, latency, demo mode), and return fields. It is complete enough for an AI agent to correctly select and invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'ip' is described in the schema as 'IPv4 or IPv6 address'. The description adds value by specifying 'public' and implicitly clarifying that private IPs are not supported. Additionally, it mentions demo mode behavior, which adds context beyond the schema. With 100% schema coverage, baseline is 3, but the extra context justifies a 4.

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 geolocates any public IPv4/IPv6 address and lists all returned fields (country, region, city, lat/lon, timezone, ISP, ASN, mobile/proxy/hosting flags). It also gives concrete use cases like traffic filtering and fraud scoring, clearly distinguishing it from sibling tools like onyx_dns_lookup or onyx_email_validate.

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

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

The description provides clear context on when to use the tool, listing specific use cases such as filtering by country, detecting datacenter/VPN egress, fraud scoring, and routing decisions. It also mentions the demo mode for testing. However, it does not explicitly state when not to use this tool or suggest 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?

No annotations provided, so description carries full burden. It discloses that signature is not verified, decoding is local and never sends the token externally, and that anomalies are reported. Provides adequate behavioral context.

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

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

The description is concise, with three sentences covering purpose, usage, and security context. It includes a price note which is somewhat extraneous but not detrimental. Front-loaded with core purpose.

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

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

Given the low complexity (single parameter, no output schema), the description is complete. It explains the decoding process, return values (claims, expiry, anomalies), and usage context. No gaps are apparent.

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% (single parameter token described). Description adds value by explaining what decoding entails (header+payload), what will be returned, and that signature is not verified, which exceeds the schema's minimal 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 decodes a JWT without verifying the signature, and lists the returned items (algorithm, key id, claims, expiry status, anomalies). It distinguishes itself from siblings as no other sibling tool handles JWT decoding.

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 provides when to use: when an agent receives a token from an external API for routing, expiry, or audit logging. It also notes the local execution and security aspect. Lacks explicit exclusions but given no alternative JWT tools, this 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 exist, so the description must disclose behavior. It states the tool fetches from /manifest with /openapi.json fallback, normalizes, and returns deltas. It also notes it is free (price $0). However, it does not disclose potential authentication needs, rate limits, or whether it writes any data. The lack of annotations is mitigated by the clear read-only nature implied by 'fetches'.

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-structured sentence that efficiently covers purpose, method, output, use cases, and pricing. Every clause adds value, with no redundancy or filler.

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

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

Given no output schema, the description provides high-level sections of the return (only-in-A, only-in-B, etc.) but omits details on formats or structure. For a comparative tool, this is sufficient for an agent to understand the output, though specific formatting (e.g., JSON structure) is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (both parameters have descriptions). The description adds no further detail about the parameters beyond 'Base URL of the first/second MCP server.' Therefore, it meets the baseline but does not exceed it.

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: performing a side-by-side diff of tool catalogs between two MCP servers. It specifies the endpoints fetched, the normalization process, and the exact return sections (only-in-A, only-in-B, same, deltas). This differentiates it from all sibling tools, which serve different functions.

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 lists use cases: competitor analysis, regression detection, and migration planning. It implies when to use this tool (any scenario requiring comparison of MCP server tool catalogs). However, it does not mention when not to use it or provide explicit alternatives, though given the unique capability, this is a minor gap.

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?

In the absence of annotations, the description discloses key behaviors: stdlib-only implementation, SSRF-hardened (refuses private/link-local), free tier no key required. It does not mention rate limiting or error handling, but the 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?

The description is information-dense yet efficient, front-loading the primary purpose and covering outputs, implementation, safety, and cost in a compact format with no redundant sentences.

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

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

Despite no output schema, the description enumerates all key output components (latencies, content types, etc.) and covers behavioral aspects like SSRF safety and cost. It provides sufficient context for a health probe 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?

Input schema provides 100% description coverage, but the description adds value by explaining the SSRF-hardening rationale for the 'server_url' parameter and reinforcing the 'must be public' constraint beyond the schema's 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 tool probes any public MCP/x402 server and returns a structured health snapshot including specific metrics. It distinguishes itself from sibling tools, none of which serve the same purpose.

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

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

The description explicitly says 'Probe any public MCP / x402 server' and notes SSRF hardening (refuses private IPs), providing a clear when-to-use and when-not-to-use. It implicitly covers availability via 'Free tier, no key', though no explicit alternatives 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?

No annotations are provided, so the description must carry the full burden. It states the tool is a 'pre-flight inspector' and is free, implying a read-only operation, but does not explicitly declare it as non-destructive or disclose any side effects. The mention of a paid v2 adds context but does not fully clarify behavior.

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

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

Three sentences, front-loaded with purpose and outputs, no unnecessary information. Every sentence earns its place, and the structure is easy to parse.

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 values (live price, chain, health, reputation, GO signal). It omits details on format or structure, but for a preflight utility, this is acceptable. Slight improvement possible by specifying the GO signal's criteria.

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 each parameter described. The description adds context by explaining the purpose of the parameters (e.g., 'used to look up reputation via agent_id logic'), but does not significantly enhance meaning beyond the schema descriptions. 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 tool is a 'Pre-flight inspector for ANY x402 tool call' and lists its specific outputs (live 402 price, recommended chain, facilitator health, caller reputation, GO signal). This distinguishes it from sibling tools as a meta-call evaluation 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 implies use before signing an x402 call, and mentions a paid tier for actual settlement, providing some context. However, it lacks explicit guidance on when not to use it (e.g., for execution) or alternatives.

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 discloses that the tool probes 5 endpoints, validates against RFCs, and returns a score and remediation list. It also mentions it is free. However, it does not detail authorization requirements, rate limits, or potential side effects, though as an audit tool, destructive actions are unlikely.

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

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

The description is concise with three sentences, front-loading the core purpose, then detailing the audit scope and scoring, and ending with a usage hint and pricing. 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?

Given the tool has one parameter, no output schema, and no annotations, the description provides sufficient context: it explains what the tool does, how it works (probing endpoints, validating RFCs), the output format (score and remediation list), and target users. This is complete for an agent to decide when to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes the single parameter 'server_url' as the base URL. The description adds minimal additional meaning, explaining it is the URL of the MCP server to audit. With 100% schema coverage, the 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 tool performs an OAuth 2.1 + RFC 7591 compliance audit for MCP servers, specifying the verb (audit), resource (OAuth compliance), and scope (5 endpoints, 0-100 score). It is distinct from sibling tools, which cover different domains like browsing, tokens, and email.

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 the tool is for MCP operators preparing for discovery by ChatGPT or Claude, but does not explicitly state when to use or avoid it, nor provides alternatives. The usage 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 provided, so the description carries full burden. It mentions returns but does not explicitly state it's read-only or disclose potential side effects, rate limits, or authentication needs. The free tier info is helpful but behavioral clarity is moderate.

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

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

The description is concise with four sentences, front-loading the core purpose and adding specifics efficiently. No redundant 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?

Given no output schema, the description explains return values (status, coverage score, remediation). It misses clarifying whether at least one parameter is needed, but is otherwise complete for a simple audit 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 description complements it by clarifying which parameter is needed for which registry. This adds value beyond the schema descriptions, justifying a 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 it performs a cross-registry listing audit for any MCP server, listing specific registries checked and what it returns. It effectively distinguishes from sibling tools like onyx_bazaar_compare and onyx_mcp_health.

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 does not explicitly state when to use this tool versus alternatives. While it implies it's for checking registrations, it lacks guidance on when not to use it or when to prefer another tool.

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 discloses that it runs locally (Stdlib-only), never sends the password, takes <5ms, and has a cost. This informs the agent about safety, latency, and resource implications.

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 front-loads the main action and proceeds with details. It's efficient with no wasted words, though slightly dense.

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 output components (entropy, diversity, length, patterns, verdict) despite no output schema. It also includes use cases and cost, making it fairly complete for a simple one-parameter 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% with a simple description. The description adds a security note about not sending the password but doesn't provide deeper parameter semantics beyond what the schema already conveys.

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 scores password strength on a 0-100 scale, listing specific factors (entropy, diversity, patterns) and verdicts. It distinguishes from all siblings, none of which are password-related.

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 says 'Use when an agent generates passwords for accounts it creates, or when validating user-supplied credentials.' This provides clear context, though it doesn't mention when not to use it (but no alternative tool for this task exists).

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 mentions data returned and pricing (non-destructive implied). However, it omits authentication requirements, rate limits, or error handling, which are important for autonomous agents.

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, all essential: first states purpose and outputs, second explains parameter, third lists use cases. Front-loaded and 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?

No output schema, but description lists expected fields (odds, volume, liquidity, etc.) and pricing. Missing return format and error handling, but adequate for agent to decide when to invoke.

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 both parameters described. Description adds minimal extra value beyond schema (e.g., 'Pass a market slug or full URL' matches schema description). Baseline 3 applies.

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

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

Clearly states verb 'lookup' and resource 'prediction-market state' with specific data fields (odds, volume, liquidity, resolution state, anomaly flags). Also lists use cases (arb agents, copy-trading, settlement-resolver), distinguishing it from unrelated sibling tools.

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

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

Explicitly tells users to pass a market slug or full URL and describes ideal use cases (arb, copy-trading, settlement). Lacks explicit 'when not to use' but context is sufficiently clear for a unique tool.

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 return values (raw text, rule, crawl-delay, verdict), performance (~50-200ms), and cost ($0.0005 USDC). It also implies non-destructive, read-only behavior. Missing details on error handling, but overall adequate for a simple 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?

Two sentences plus a brief time/cost note; no wasted words. The primary action and returns are front-loaded, making it efficient for an agent to parse.

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

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

Given the tool's simplicity and no output schema, the description covers the key aspects: purpose, inputs, returns, and cost/performance. It lacks explicit error handling or edge cases (e.g., missing robots.txt), but this is likely acceptable for a straightforward check 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 the schema already describes both parameters. The description adds usage context but does not clarify the relationship between 'url' and 'path'—the path is implied from the URL, which might confuse agents expecting a separate path parameter. 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 the tool fetches robots.txt and checks if a path is allowed for a user-agent. It is distinct from sibling tools like browser navigation or DNS lookups, making its purpose unambiguous.

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

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

The description advises using the tool when 'an agent does web scraping and wants to be polite,' providing clear context. However, it does not explicitly exclude cases or name alternatives, though siblings like onyx_browser_navigate might be misused without this guidance.

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

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

No annotations provided, so the description carries the full burden. It discloses the tool is free ($0 USDC, tier: free) and differentiates v1 (analysis) from v2 (settlement). However, it does not elaborate on what 'brokers settlement' entails (e.g., transactions, permissions), leaving some behavioral ambiguity.

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, front-loading the core purpose and outputs. Every sentence adds essential information without redundancy. Parenthetical price/tier is efficiently appended.

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

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

No output schema exists, so the description must explain return values. It lists four output components (cost preview, prerequisites, settlement count, bundle fit) and versioning. However, it lacks specifics on output format (e.g., JSON structure), which could be clarified.

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 beyond schema by explaining the output semantics (unified cost preview, prerequisites, etc.) and versioning, which helps the agent understand the tool's value beyond parameter definitions.

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: 'Plan a multi-tool agent workflow under one x402 budget cap.' It specifies inputs (list of tool endpoints, max-spend cap) and outputs (unified cost preview, per-step prerequisites, estimated total settlement count, bundle fit). It also distinguishes between v1 and v2, making the function specific and distinct from siblings.

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

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

The description implies usage for budget-constrained workflow planning but does not explicitly state when to use this tool versus alternatives like onyx_x402_simulate or onyx_x402_facilitators. It mentions v1 (analysis card) and v2 (brokers settlement) but lacks clear 'when-not-to-use' or alternative guidance.

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

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

No annotations provided, so description carries full burden. It discloses the tool's nature (quote only, not execution), mentions price impact, expected output, intermediate hops, and slippage. Also explains pricing ($0.001 USDC). Does not cover rate limits or error behavior, but sufficient for a simple quote 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, efficiently conveying purpose, parameters, usage guidance, and pricing. Front-loaded and 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?

No output schema, but description mentions expected output (price impact, expected output, intermediate hops, slippage). Adequately covers the tool's functionality for an AI agent to use it correctly. Could detail error cases or response structure, but 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% with all parameter descriptions. Description adds minimal extra: confirms amount is in smallest units and mentions slippage_bps default. Baseline 3 as description adds little beyond 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 provides the best-route swap quote via Jupiter aggregator on Solana. It lists supported DEXes and distinguishes itself from sibling tools (e.g., onyx_base_tx_decode, onyx_solana_tx_explainer) by focusing specifically on quote retrieval.

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 says 'Use BEFORE every Solana swap to lock execution price', giving clear context. Mentions pricing comparison to alternatives, but does not explicitly state when not to use or name specific alternatives (aside from implied cheaper).

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 discloses method (reads Mint account, derives PDA) and cost, but does not explicitly confirm read-only nature or mention what happens on errors.

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 plus parenthetical, dense information, no fluff. Front-loaded with main purpose.

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

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

Covers core functionality and cost, but omits explanation of the nested 'input' parameter and error handling. Lacks output schema description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 50% description coverage; description adds 'base58-encoded' prefix already in schema and does not explain the unspecified 'input' parameter. Minimal additional value beyond 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?

Clearly states the verb 'Resolve' and resource 'SPL token metadata', lists specific fields (name, symbol, decimals, total supply), and distinguishes from sibling 'onyx_solana_token_risk_scan' by noting it pairs with it.

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 by mentioning pairing with risk scan and comparing cost to alternatives, but does not explicitly state when not to use or give alternatives for non-Solana tokens.

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 must disclose behavioral traits. It describes the tool as a read-only scan that checks risk factors and returns scores, which implies non-destructive behavior. However, it does not explicitly state that it does not modify state, nor does it mention any rate limits, permissions, or error conditions. The transparency is adequate but not comprehensive.

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 reasonably concise at four sentences, with the main purpose front-loaded. However, it includes pricing and competitor comparisons that are not essential for an AI agent's tool selection, adding unnecessary verbosity. It could be trimmed to improve focus.

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 lack of output schema, the description should detail return values and error conditions. It mentions a risk score, verdict, and ranked risk factors but does not specify the structure or possible error cases (e.g., invalid mint address). This leaves the agent with incomplete information for interpreting results or handling failures.

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 50%, and the description only adds context for the 'mint' parameter by explaining what the tool does with the address. The 'input' parameter, which contains a required 'method' field, is not mentioned in the description, leaving its purpose unclear. The description does not sufficiently compensate for the low schema coverage.

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

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

The description clearly identifies the tool as a rug-vector risk scan for SPL tokens on Solana mainnet, enumerating specific checks (mint authority, freeze authority, holder concentration, etc.) and output types (risk score, verdict). This leaves no ambiguity about the tool's function and differentiates it from sibling scan tools like onyx_base_token_risk_scan by specifying the blockchain.

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 states it is designed for memecoin/sniper/MEV agents needing a pre-trade gate, implying when to use it. However, it does not provide explicit guidance on when not to use it or mention alternatives, such as onyx_base_token_risk_scan for other chains. The inclusion of pricing details adds context but does not clarify usage 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 provided, but description details output: one-line summary, token/balance deltas, programs, compute units, fee. Also mentions pricing (cost, tier). No destructive behavior indicated, fitting for a read-only decode 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?

Front-loaded with purpose and output details. While it includes some marketing fluff (e.g., '1,350+ unique paying agents'), it remains concise enough and well-structured for an agent to parse.

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 use cases, output structure, and pricing adequately for a decode tool without output schema. Slightly lacking in error handling or optional parameter guidance, but sufficient given the tool's complexity.

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 has two parameters (input and signature) with 50% coverage. Description only mentions the signature parameter, repeating its schema description. The 'input' parameter is entirely undocumented in both schema and description, failing to compensate for the coverage gap.

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 'Decode a Solana mainnet transaction into a human-readable summary', specifying the verb and resource. Distinguishes from siblings like onyx_base_tx_explainer by targeting Solana and emphasizing human-readable output.

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 describes when to use: for verifying a Solana transaction or explaining it to a user. While it doesn't contrast with sibling tools directly, the 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?

No annotations provided, so description carries full burden. It explains what is returned, mentions 'best-effort classification', and notes performance (sub-second feed). No destructive actions implied. Sufficient for a read-only query.

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 reasonably concise and front-loaded with purpose and output. Includes marketing comparisons which add some length but provide useful context. Could be slightly tighter.

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 2 params and no output schema, it covers purpose, output details, use cases, performance, and cost. Missing error handling or pagination but sufficient for typical use.

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. Description does not add significant meaning beyond the schema; it restates default and max for limit, which are already in the schema. No additional parameter context.

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 'Recent on-chain activity for any Solana wallet' and specifies returns signatures with slot, block_time, status, fee, and program/action classification. Distinguishes from siblings like token metadata or tx explainer.

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 says designed for whale-watching, copy-trading, risk-monitoring. Provides clear use cases but does not explicitly exclude alternatives or mention when not to use.

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, but the description discloses latency (30-80ms), accuracy (70-90%), the OCR engine (ddddocr), pricing ($0.003 USDC), and that it can fetch URL or accept base64. This fully informs the agent about behavior.

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

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

The description is compact (5 sentences) and front-loaded with the core purpose. Every sentence adds value: purpose, examples, technical details, usage guidance, pricing. 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 no output schema, the description explains the return value (recognized text). It covers constraints (not for reCAPTCHA), alternatives, pricing, latency, accuracy, and input options. This is comprehensive for a captcha solver 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 context by explaining that image_url is for fetching on behalf, and image_b64 is for raw bytes if already available, which clarifies the two options 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 states it solves image-based text captchas and returns recognized text. It specifies the type of captchas (standard alphanumeric) and provides examples (web signup forms, login walls, scraping checkpoints). It also distinguishes itself from reCAPTCHA and hCaptcha.

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 says 'Use when an agent encounters a captcha mid-task and needs to continue without human intervention.' Also contrasts with 2captcha (cheaper and faster for simple captchas) and states it is not designed for reCAPTCHA or hCaptcha.

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

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

With no annotations provided, the description carries the full burden. It discloses that reads are via Base public RPC, typical latency of 150-300ms, no vendor key needed, and mentions pricing. It implicitly indicates read-only behavior through terms like 'lookup' and 'confirms,' providing sufficient transparency for safe invocation.

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 efficiently structured: purpose first, then usage context, performance, pairing, and pricing. Every sentence serves a distinct purpose with no redundancy, making it highly concise and front-loaded.

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

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

For a simple one-parameter tool with no output schema, the description covers all necessary information: what it does, when to use it, performance characteristics, external dependencies, and pricing. It also references a companion tool, making the context complete for the agent's decision-making.

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 the single 'address' parameter already described as '0x-prefixed ERC-20 contract address on Base.' The description repeats this same information, adding no additional semantic value beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description clearly identifies the tool as an ERC-20 token metadata lookup on Base mainnet, listing specific fields (name, symbol, decimals, total supply) and the purpose: confirming a contract is a real ERC-20 and resolving human-readable identity. It distinguishes itself from siblings like onyx_base_tx_decode by noting its use before transacting and pairing context.

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 recommends use before transacting with a token discovered at runtime and mentions pairing with onyx_base_tx_decode for full context. While it doesn't state when not to use it, the guidance is clear and practical for the intended scenario.

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 important behavioral traits: 'Stdlib only, no network calls, <1ms' and cost. No annotations are provided, so the description effectively communicates safety and performance. No contradictions.

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

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

Two sentences: first defines purpose and output, second adds usage and performance. No unnecessary words, 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?

For a simple parse tool with one parameter and no output schema, the description fully explains what it does, when to use it, and the behavioral characteristics.

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 a simple 'url' parameter. The description adds context on what the output includes but does not add further semantics to the parameter 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 starts with a clear verb (Parse) and resource (URL), and enumerates the structured components returned. This distinguishes it from sibling tools like onyx_url_unshorten or onyx_url_text.

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 explicit use cases: inspect, modify, validate a URL, change query param, strip tracking, normalize for caching. No explicit exclusions or alternatives, 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, the description fully discloses behavior: returns plain text, page title, word count, final URL after redirects; output capped at 200kB; typical latency 150-800ms; price and tier mentioned. This covers key behavioral traits beyond what annotations would provide.

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

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

The description is concise and well-structured: first sentence states the core action, followed by usage context, return details, and performance/pricing. Every sentence adds value with no redundancy, making it easy to scan.

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 no annotations, the description covers core aspects: what it does, return values, limitations, performance, and pricing. It lacks explicit error handling details (e.g., unreachable URL), but for a simple fetch tool this is a minor gap.

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 minimal extra value by mentioning the output cap (200kB) in relation to max_chars, but the schema already describes max_chars as 'Truncate output (max 200000)'. No significant addition 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 fetches any public URL and returns readable text content, specifying what is stripped (HTML/scripts/styles) and what is returned (plain text, page title, word count, final URL). It provides specific use cases (docs pages, articles, etc.), distinguishing it from siblings like onyx_url_unshorten.

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 guides when to use the tool: 'Use when an agent needs to reason over a web page without rendering a browser' and lists example scenarios. It doesn't explicitly state when not to use it, but the sibling tool onyx_url_unshorten provides an implied alternative for URL expansion.

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

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

With no annotations, the description carries the burden. It discloses a 10-hop cap, typical 100-400ms latency, and cost ($0.0005 USDC). Does not cover error handling or auth, but for a simple lookup tool this is sufficient.

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?

Concise two-sentence description: first sentence defines action and output, second provides usage guidance and technical details. Efficiently structured with no redundant 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 tool's simplicity (single input, no output schema), the description fully covers purpose, usage, behavioral details, and constraints. It explains return values (redirect chain with status/location) and limits, making it complete for agent decision-making.

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 sole parameter 'url' has schema description 'URL to unshorten'. The tool description adds context about what the tool does but no additional detail about the parameter format, validation, or constraints beyond schema. Schema coverage is 100% so baseline 3 is appropriate.

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

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

The description clearly states the tool follows HTTP redirects to find the final destination and redirect chain, using specific verb+resource. It is distinct from sibling tools which cover different network utilities.

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 recommends use when encountering shortened links (bit.ly, t.co, lnkd.in) and implies not to use for non-shortened URLs. Does not explicitly mention alternatives but siblings are clearly different.

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

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

With no annotations, the description carries the full burden. It discloses that it uses 'Stdlib regex only — works offline, no external lookups. <2ms.' and includes the price. This provides good insight into behavior, though edge cases or error responses are not mentioned.

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 two sentences, front-loaded with the core function, and contains no fluff. Every sentence adds value: purpose, output fields, use cases, performance, and cost.

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 simple input (one string) and no output schema, the description covers purpose, output structure (browser, OS, device, engine), performance, and cost. It could be more explicit about the return format, but 'structured record' suffices.

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 the parameter 'user_agent' described as 'User-Agent header value'. The description adds context about the tool's purpose but does not add semantics beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool parses HTTP User-Agent strings into structured components (browser, OS, device type, engine), and lists use cases like analytics and fraud scoring. This verb+resource combination is specific and distinguishes from sibling tools.

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

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

The description explicitly mentions when to use (analytics, fraud scoring, routing logic) and highlights offline capability and speed. However, it does not state when not to use or suggest alternatives 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?

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?

The description discloses key behavioral traits: it uses the RDAP protocol via rdap.org (free tier, no API key), typical response time of 200-500ms, and cost of $0.001 USDC per call. This goes beyond the schema, though rate limits are not mentioned.

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, well-structured, and front-loaded with the core function. Every sentence adds value (purpose, data fields, use cases, source, performance, cost) 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?

For a simple tool with one parameter and no output schema, the description covers all relevant aspects: what it does, what data it returns, when to use it, performance, cost, and external source. It is complete enough for an agent to decide to invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully describes the single 'domain' parameter with an example. The description adds context about usage but no additional parameter-level details, so it adds marginal value beyond the schema.

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

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

The description clearly states the tool performs domain whois via RDAP and lists the specific data returned (registrar, dates, nameservers, etc.). It distinguishes from sibling tools like onyx_dns_lookup by focusing on domain registration information.

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 use cases: vetting domains for fraud risk, checking trademark conflicts, and confirming ownership transfer. It does not explicitly compare to siblings but the distinct function implies when to use this tool over others.

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 bears full responsibility for disclosure. It reveals that the tool ranks chains using specific criteria, returns a ranked list with explanations, and is free tier. It does not mention auth needs, rate limits, or side effects, but given the non-destructive, read-only nature inferred, the behavioral context is adequate.

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

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

The description is concise: two sentences that efficiently convey purpose, input, output, and a usage hint. It is front-loaded with the primary action, and every sentence adds essential information 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 3 parameters, 100% schema coverage, and no output schema, the description sufficiently covers what an agent needs: input requirements (target amount, optional chains, testnet filter), behavior (ranking criteria), and output (ranked list with explanations). The free tier note and the hint about not hardcoding complete the context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are documented. The description adds value by explaining the tool's ranking logic and output (ranked list with explanations), which the schema does not cover. It also clarifies the default for available_chains and the role of production_only, going beyond the schema's basic 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: 'Pick the optimal chain for an x402 USDC payment.' It specifies the ranking criteria (facilitator support, gas, finality, USDC contract maturity) and output (ranked list with explanations). This distinguishes it from sibling tools like onyx_x402_facilitators or onyx_solana_jupiter_quote, which cover different aspects.

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: 'Given target amount + agent's available chains' and includes a practical tip: 'agents shouldn't hardcode 'base' when their wallet has L2 options.' It implicitly tells when to use (when selecting a chain for x402 payment) but lacks explicit when-not-to-use or alternative tool references.

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 properly discloses that keys are deterministic and not secure, that it generates ephemeral wallets, and that it reports balances and emits config. No hidden side effects or destructive actions are mentioned, and the sandbox-only restriction is clear.

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-structured sentence that front-loads the purpose and lists all key features. Every part adds value, with no redundancy or 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?

For a simple demo tool with no output schema, the description covers inputs, behavior, limitations (not for real value), output type (env config), and cost. It is complete for the agent to understand and invoke 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 descriptions cover both parameters fully (100% coverage). The description adds behavioral context: seed determines address, and if omitted, generates one. This adds meaning beyond the schema, justifying a score above baseline 3.

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

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

The description clearly states it is a 'Dev-sandbox wallet helper for x402 testing' and lists specific actions: generate deterministic wallet, report balances, point to faucet, emit env config. It distinguishes itself from siblings by focusing on wallet operations for testing, unlike other x402 tools like simulation or lookup.

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 warns 'SANDBOX ONLY — generated keys are deterministic and MUST NOT receive real value,' and mentions free cost. It implies usage for x402 testing, though it does not explicitly say 'use this when you need a sandbox wallet for x402 testing' or compare with alternatives among siblings, which are not direct competitors.

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 mentions local logic, no network calls, and covers various error types. However, it does not disclose limitations (e.g., might not cover all possible errors), side effects, or confidentiality of passed data. With no annotations, more transparency 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 four sentences, front-loaded with purpose. Every sentence adds value: explains what it does, how to use it, what it covers, and pricing. No extraneous words, and it is well-structured for quick comprehension.

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

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

The tool has no output schema, so the description should cover what the output looks like. It says 'diagnosis with specific cause and actionable fix,' which is good. It also covers the error domains. However, it does not specify the output format (e.g., plain text vs. structured JSON). For a tool with no output schema, this is a minor gap. Score 4.

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: 'Pass the status code + response body (or headers),' which clarifies usage pattern. It also mentions optional request_summary. However, it does not add significant depth beyond the schema's parameter descriptions, so a 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's purpose: 'Plain-English explainer for any HTTP error in an x402 / MCP flow.' It specifies the action (explain), the resource (HTTP errors in x402/MCP flow), and covers specific areas like FastAPI validation, OAuth2 DCR failures, etc. This distinguishes it from sibling tools which are mostly unrelated.

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 'Pass the status code + response body (or headers), get back a diagnosis...' This clearly indicates when to use the tool (when encountering an HTTP error in x402/MCP flow). It also mentions 'Free tier — local logic, no network calls,' which helps set expectations. However, it does not explicitly state when not to use or list alternatives, though given the sibling tools are different, this is not a major gap.

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 it's free, refreshes per call, requires no API key, and performs live reachability probes. Implicitly read-only. Could be more explicit about non-destructive nature but overall adequate.

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 one paragraph but includes all key info: data fields, pricing, use case. Could be slightly more structured (e.g., separate sentences), but no wasted words and front-loaded with core purpose.

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

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

Given no output schema, description lists the data points returned (reachability, networks, auth scheme, latency) which is sufficient. Explains refresh behavior and cost. Completeness is adequate for a simple directory 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 schema already documents both parameters. Description adds context like 'filter facilitators that support this network' and 'include ones that didn't respond', but largely restates schema info. Meets baseline without adding significant new meaning.

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 it's a directory of x402 facilitators with specific data fields (live reachability, networks, auth scheme, latency). Distinguishes from sibling tools like onyx_x402_simulate and onyx_x402_spec_lookup by focusing on discovery and routing.

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 agents use this to choose routing for /verify and /settle calls. Mentions free tier and refresh behavior. Does not explicitly say when not to use, but purpose is clear enough for an AI 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 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?

With no annotations, the description fully describes the tool's behavior: it fetches challenges, parses requirements, generates a template payload, and returns next-step guidance. It also mentions SSRF-hardening and pricing, providing comprehensive behavioral context.

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

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

The description is concise (four sentences) and front-loaded with the core purpose. Every sentence adds value: action, process, simulation emphasis, and security/pricing details. 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?

The tool has no output schema, but the description explains it returns 'next-step guidance' and a template payload. While it does not detail the output structure, it provides enough context for an agent to understand the simulation output. Minor ambiguity about 'next-step guidance' prevents a perfect score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description does not add substantial meaning beyond the schema's own parameter descriptions. It reinforces the overall flow but does not introduce new details about the parameters themselves.

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 simulates an x402 v2 payment flow against any paid endpoint, using specific verbs and resources. It distinguishes itself from sibling tools like onyx_x402_facilitators and onyx_x402_spec_lookup by focusing on simulation, not facilitation or spec lookup.

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 'Pure simulation — no keys, no signing, no payment', clearly indicating when not to use it (for actual payments) and its safe, non-transactional nature. However, it does not name alternative tools for different 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 must fully disclose behavior. It states the tool is free, uses embedded knowledge (no network), and returns a snippet and fix. However, it does not describe behavior for unrecognized queries, error handling, or output format specifics, 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 concise and front-loaded with the core purpose. It includes a marketing claim ('Replaces 30 minutes...') and free-tier note, which are slightly extraneous but do not significantly bloat the text.

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

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

The tool has one parameter, no output schema, and no annotations. The description sufficiently covers input types, output nature (snippet + fix), and context (free, no network). It does not detail output format but is otherwise complete for its simplicity.

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 a rich description for the single parameter 'query', listing valid input types. The tool description recapitulates those types but adds no 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?

The description clearly states the tool's purpose: looking up x402 v2 protocol spec terms (error strings, HTTP status, header names, payload fields, feature keywords) and returning a spec snippet with plain-English fix. It is distinct from sibling x402 tools (facilitators, simulate) which are not reference lookups.

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 positions the tool as a quick reference to replace manual spec-grepping, implying use when needing spec information. It does not explicitly state when not to use or list alternatives, but the context is clear given sibling tools differ in function.

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