onyx-mcp

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

The description claims 'Returns every USDC outflow,' but the input schema includes a limit parameter (default 30, max 100) that truncates results, creating a potential contradiction. No annotations are provided, so the description carries full burden; it does not disclose the truncation behavior, rate limits, or whether the tool is read-only. The lack of transparency about limitations lowers the score.

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

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

The description is relatively concise at about 50 words, front-loading the main action and key outputs. It includes use cases and pricing, which adds value. A slightly tighter structure could remove marketing fluff, but it remains 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?

The description lists the exact fields returned (destination, tool name, timestamp, tx hash, etc.), which partially compensates for the lack of an output schema. However, it does not specify the return format (e.g., array of objects) or how to interpret risk flags, leaving some ambiguity. Given the tool's complexity, a bit more structure would improve completeness.

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

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

Schema coverage is 100%, and the schema already describes all three parameters (wallet, limit, lookback_blocks) with clear documentation. The description only adds context about the tool's overall output but does not enhance understanding of individual parameters beyond the schema. Thus, baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns a full audit trail for any agent wallet on Base, listing specific data fields (USDC outflow, destination, tool name, etc.). The verb 'Returns' and resource 'audit trail' are unambiguous. It distinguishes itself from siblings like onyx_agent_budget_tracker by focusing on historical transaction records rather than budget management.

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 for when to use the tool: for compliance, ops review, and anomaly detection. It says 'every agent operator needs' this audit log. However, it does not explicitly state when not to use it or mention alternative tools, which would 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?

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?

No annotations are provided, so the description carries full burden. It discloses key behaviors: reads public RPCs (Base + Base Sepolia), no API key needed, free tier, and returns a reputation card with specific metrics. It does not mention destructive actions, consistent with a read-only tool. Score slightly limited because it doesn't detail data freshness or caching 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 front-loaded with the primary action, lists output components, and then provides technical details (RPCs, keyless) and use cases. Every sentence adds value; no wasted words. Length is appropriate for the complexity.

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

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

Given no output schema, the description adequately explains the return value (reputation card with USDC settlements, recipients, volume, score) and the source (Base RPCs). It also covers parameter semantics and use cases, making the tool fully understandable for an AI agent.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning: '0x-prefixed EVM wallet address' for wallet_address and 'Include Base Sepolia activity in the score (test traffic)' for include_sepolia, but these largely restate 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 the tool's purpose: 'Look up an agent (EVM wallet) and return a reputation card'. It specifies key metrics (USDC settlements, recipients, volume, reputation score) and distinguishes itself from siblings like onyx_agent_audit_trail by focusing on reputation rather than history or budgets.

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

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

The description provides explicit usage context: 'useful for tools deciding rate limits, returning-customer discounts, or trust extension'. It implies when to use it but does not explicitly list when not to use or compare to alternatives, though the sibling list makes differentiation 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 discloses behavioral traits: explains that on-chain facts are attested by Onyx and ratings are opinion (not objective), mentions Ed25519-signed output, and lists pricing ($0.25 USDC) and tier (metered). This is comprehensive and honest.

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

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

The description is front-loaded with the core purpose and each sentence adds value: outputs, signing, opinion disclosure, usage context, unregistered warning, and pricing. No fluff or 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 covers all necessary context: input (agent_id), output (identity, wallet, AgentCard URI, reputation summary with rating and score), behavioral notes (signed, opinion), and usage guidance. Without an output schema, it fully explains the return values.

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

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

The input schema already describes agent_id as 'the ERC-8004 identity id (the ERC-721 tokenId in the IdentityRegistry).' The description adds no further detail beyond reinforcing the parameter's role, so it meets but does not exceed the baseline for 100% 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 states the tool's purpose: 'Vet another AI agent before you trust it' via ERC-8004 registries. It lists specific outputs (on-chain identity, wallet, AgentCard URI, reputation summary) and distinguishes from siblings like onyx_agent_id by focusing on reputation assessment.

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 when to use: 'before paying, delegating, or accepting its output.' It also notes 'Unregistered = unverifiable.' However, it does not mention alternatives or when not to use, missing a chance to differentiate from similar tools.

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

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

With no annotations, the description fully discloses key behaviors: stops on first error and returns partial results, cheaper than separate calls, atomic execution, pricing, and referencing syntax ($ref, $prev). 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?

The description is front-loaded with the core purpose, followed by syntax, benefits, example, error behavior, and pricing. Every sentence adds unique value, 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?

For a tool with no output schema, the description covers input format, referencing, error handling, and pricing. It omits the success return structure, but given the complexity, it is largely complete.

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

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

Schema coverage is 100%, baseline 3. The description adds value by explaining that steps can reference earlier outputs via $ref and $prev, and that it stops on first error, going beyond 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 the verb ('run'), resource ('multi-step workflow across Onyx tools'), and key feature ('in one paid call'). It distinguishes from sibling tools by emphasizing orchestration of multiple 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?

Provides clear context for when to use: 'Saves agents the round-trip + per-call gas...when they know the chain in advance' and gives an example. Lacks explicit when-not-to-use or alternatives, but the guidance is specific.

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

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

No annotations are provided, so the description bears the full burden. It describes the tool as a 'signed reading' and states 'Never fabricated', implying reliability. However, it does not disclose any limitations, rate limits, error handling, or whether the output is cached or real-time, which would be beneficial for a tool with no annotations.

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

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

The description is concise, consisting of two sentences plus parentheticals. It front-loads the purpose and key output details. The inclusion of price and tier is informative but slightly adds clutter; overall, it is well-structured with minimal waste.

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

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

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

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

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

Schema description coverage is 100% with good descriptions. The tool description adds value by providing examples (e.g., 'Onyx Protocol', 'AI agent payment rails') and explaining how the category drives the 'best <category>' query, thus adding context beyond the schema.

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

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

The description clearly states it is an AI answer-engine visibility oracle, specifying the input (brand/product) and detailed outputs (presence, recommendation set, sentiment, share-of-voice, cited sources, visibility score). It distinguishes itself from siblings by calling it 'the new SEO' and 'one per-call x402 tool'.

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

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

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

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

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

With no annotations, the description 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, so description fully discloses behavior: returns Ed25519-signed verdict (ALLOW/REVIEW/BLOCK), detects unlimited approvals, EOA spender, contract verification. Also mentions pricing and tier.

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

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

Descriptive and well-structured, but could be slightly more concise. Front-loaded with purpose and safety context. Earns its length by covering critical details.

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

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

No output schema, yet description explains the return value format (signed verdict). Covers all necessary aspects for effective use, including cost and tier.

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

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

Schema coverage is 100%, but description adds significant meaning: explains spender as the recipient of approval, token as context, amount_raw to detect unlimited/max approvals. Provides rationale for each parameter.

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?

Clear verb+resource: 'Pre-approval firewall' and 'safety check before signing approve()'. Distinguishes itself by focusing on token approval safety, not covered by siblings like onyx_tx_guard or onyx_signature_guard.

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 when to use: before any approve() call. Describes what it checks (unlimited amount, EOA spender, verified contract). Lacks explicit alternatives but purpose 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 carries the burden. It explains the process (queries CDP corpus, computes delta, produces pitch) and includes pricing info. Lacks details on data freshness or error handling, but sufficient for most 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?

Concise, front-loaded with purpose, no filler. 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?

Given no output schema, description hints at return (one-line pitch). Parameter set is small and well-described in schema. Missing details on error cases or empty results, but overall satisfactory for the 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 coverage is 75%, so baseline is 3. Description provides example capability values but does not elaborate on parameter meaning beyond the schema. Adequate but not added value.

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

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

The description clearly defines the tool's purpose: price arbitrage between Onyx Actions and peer x402 services, with specific examples like 'tx_explainer' and output format.

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 use cases: competitive intel, marketing copy, or pricing decisions. Does not mention when not to use or alternative tools, but gives clear 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, the description explains the cryptographic checks (Ed25519 signature, kid, tamper detection) and declares the tool as 'FREE' with price $0. It lacks details on error handling or rate limits, but covers core behavior well.

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

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

The description is concise and well-structured: starts with the verb 'Verify', explains usage, then the outcome, and ends with supplementary info (free, cross-check). Every sentence is purposeful.

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

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

For a single-parameter tool with no output schema, the description fully explains what the tool does, how to use it, what results to expect, and even provides a verification tip. It is contextually complete.

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

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

The description reinforces the schema's parameter description and adds meaning by explaining what the verification yields (validity of signature, kid, tamper status). Since there is no output schema, this additional context is valuable.

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

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

The description clearly states the tool verifies Onyx-signed security verdicts, including cryptographic signature verification, key identification, and tamper detection. It distinguishes from siblings by being the sole verification tool for Onyx attestations.

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

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

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

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

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

No annotations provided, so description carries full burden. It describes return values (toAmount, fee breakdown, gas cost, etc.) and mentions aggregator and bridges. However, it does not explicitly state that this is a read-only quote (no side effects) or disclose potential limitations (e.g., rate limits, authentication needs). 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 concise: two sentences plus pricing note. It front-loads the core purpose. The pricing information could be placed elsewhere, but does not detract significantly. Efficient use of words.

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

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

Given no output schema, the description adequately explains return values and the aggregator used. It covers the main purpose and usage scenario. Could mention that this is only a quote and not the actual bridge execution, but overall complete for a quote 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 description coverage is 100%, so parameters are already well-documented. The description adds no additional parameter-level semantics beyond what the schema provides. 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 provides a cross-chain bridge quote starting from Base, using LI.FI aggregator across ~30 bridges. It distinguishes from sibling onyx_base_swap_quote by specifying 'starting from Base' and being a bridge quote, not a swap. The return values are enumerated, making the purpose unambiguous.

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

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

Explicitly says 'Use when an agent on Base needs USDC/ETH/etc. on another chain.' This provides direct usage context. It does not explicitly state when NOT to use, but the sibling list includes onyx_base_swap_quote for same-chain swaps, implying the exclusion. Slightly lacking explicit alternative mention.

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 reveals important behaviors: auto-detects proxy types, resolves to implementation, backed by Blockscout (free, no auth), and pricing tier. It does not discuss rate limits or error handling, but core behavioral traits are covered.

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

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

Three sentences, each earning its place: first states output, second explains backend and proxy feature, third gives usage advice and cost. No fluff, front-loaded with 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?

The description covers purpose, usage, features, pricing, and lists return fields despite no output schema. It omits error handling and doesn't detail the ABI entry count vs full ABI distinction, but overall completeness is high for a verification 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%, but the description adds value beyond schema by explaining proxy detection relevance (resolve_proxy), warning about source code size (include_source), and mentioning that include_full_abi can be large. This context aids parameter selection.

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: 'Contract verification + ABI metadata for any Base address.' It lists specific return fields and features like proxy detection, distinguishing it from sibling tools that handle trading, risk, or transactions.

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

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

The description explicitly advises using this tool 'before any swap or interaction' and highlights that unverified contracts are a red flag. It provides context on free access and pricing but does not explicitly mention when not to use 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?

With no annotations, the description carries full burden. It discloses the data source (DexScreener, free), sorting, and exact fields returned, implying a read-only operation. It lacks explicit mention of rate limits or auth, but the tone and content are sufficient for typical usage.

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), front-loaded with the core functionality and use cases. Every sentence adds value, including the pricing note which is non-essential but informative.

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

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

Given no output schema, the description adequately explains return values and sorting. It lacks details on error handling or timeout behavior, but for a simple lookup tool this is acceptable and matches the 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 description coverage is 100%, so baseline is 3. The tool description does not add additional parameter semantics beyond what is already in the schema (token_address and limit descriptions are self-explanatory). No extra value from 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 retrieves DEX pairs for a Base token with specific fields (DEX name, price, volume, liquidity, price change, fees) sorted by liquidity. It distinguishes from siblings like onyx_base_swap_quote (for quotes) and onyx_base_token_risk_scan (for risk) by focusing on trading venue discovery.

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

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

The description explicitly advises using this tool before routing a swap or assessing rug risk via volume/liquidity ratios, providing clear context. It does not, however, name specific alternatives or 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?

Since no annotations are provided, the description carries the burden. It discloses the read nature (fetch), return structure (logs with topics, raw data, block+tx info), and optional decoding for common ERC events. It also mentions pricing and tier. It does not mention rate limits or authentication, but overall is transparent.

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

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

The description is concise with two sentences plus a pricing note. It is front-loaded with the main action and provides essential details without fluff.

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

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

Given no output schema, the description adequately explains return structure and supported features. It could mention pagination (limit parameter) more explicitly, but the schema covers it. Overall, it is complete for 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 coverage is 100% with descriptions for all 5 parameters. The description adds value by explaining the default block range (last 100 blocks) and that topic-0 filters for specific events, and that decoding applies to common ERC-20/721/1155 events.

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 fetches contract event logs from Base mainnet using eth_getLogs, with specific features like block range and topic-0 filtering. It distinguishes itself from sibling tools as the only event log retrieval 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 provides clear guidance on when to use the tool (fetching event logs) and mentions features like block range and topic-0 filtering. However, it does not explicitly state when not to use it or compare to 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 provided, so description must bear the burden. It mentions returning specific data (amountOut, etc.) and implicitly indicates read-only behavior via 'quote'. Could explicitly state no state changes, but the listed outputs and context suffice.

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. Front-loaded with core function and DEX list. Every sentence adds value; no filler.

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

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

Given no output schema, the description lists key return fields (amountOut, USD value, gas estimate, etc.), covers inputs, and notes pricing. Complete for its 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 coverage is 100% with descriptions. The tool description adds value with examples (WETH address, atomic amount format) and clarifies that parameters are tokens. This goes 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 clearly states it provides best-route swap quotes on Base across multiple DEXes, listing expected outputs. It distinguishes itself from the sibling onyx_solana_jupiter_quote by specifying 'on Base' and referencing Jupiter's Solana role.

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 'most agents need this before any on-chain swap', indicating when to use. Does not specify when not to use or list alternatives (e.g., onyx_base_bridge_quote for bridging), but the context is clear for a swap quote 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 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?

No annotations exist, so the description carries full burden. It discloses that the tool reads CDP data (non-destructive), returns specific structures (empty_niches, thin_niches, saturated, recommended build target), and mentions pricing ($0.01 USDC, tier metered). It does not cover error conditions or rate limits, but key behavioral aspects are 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 three sentences, each serving a distinct purpose: purpose, usage guidance, return structure. It is front-loaded with the action and resource, contains no redundant or extraneous text, and is highly efficient.

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

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

The tool has moderate complexity with 3 parameters and no output schema. The description covers purpose, usage, return details, and pricing. It lacks information on error handling or edge cases, but for a read-only market analysis tool, the provided context is largely sufficient for an agent to select and invoke 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?

Schema coverage is 67% (two of three parameters described). The description adds meaning: for 'network' it clarifies variant handling, and for 'seed_keywords' it explains the auto-mine fallback. 'max_niches' lacks explicit description, but the tool description implies its role in limiting output. Overall, the description enhances schema information.

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: 'Find empty niches in the x402 paid-MCP market.' It specifies the action (find), resource (empty niches), and methodology (reads CDP discovery, clusters by keyword). This clearly distinguishes it from sibling tools like onyx_bazaar_compare or onyx_bazaar_submit.

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

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

The description explicitly advises when to use: 'Use to position a new paid tool in an uncontested slot.' It provides clear context for usage but does not mention when not to use or list alternative tools, though the purpose is self-contained.

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 the data source (Coinbase Bazaar via Onyx mirror), refresh frequency (15 minutes), and pricing (free). With no annotations, this is sufficient transparency 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 concise (two sentences plus a note) and front-loaded with purpose. Every sentence adds value, with no redundancy or 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 comparison tool without an output schema, the description covers inputs, filtering, sorting, and data source. It lacks details on output format but suffices for an agent to understand the tool's behavior.

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

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

The description adds examples and context for parameters beyond the schema (e.g., keyword examples like 'captcha', 'tx_explainer'). Schema coverage is high, but the description enriches 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?

The description clearly states this tool performs a side-by-side comparison of paid agent tools, with filtering and ranking. It distinguishes from sibling bazaar tools like 'onyx_bazaar_blue_ocean' and 'onyx_bazaar_submit'.

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 instructions on how to filter by keyword and network, and rank by price, volume, or payer count. It mentions data refresh and free tier, though it does not explicitly state when to use 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, the description carries a heavy burden. It discloses atomic delivery (all-or-none), receipt behavior, pricing, and bundle composition. It does not detail error handling beyond the stop_on_error parameter or auth requirements, but provides significant 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?

Two sentences plus a list of bundles with constituent tools. Front-loaded with purpose and key benefits. No wasted words, efficient and clear.

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 does not explain what the agent receives after execution. While it mentions 'one AR-1 receipt for the whole chain', the output structure is unclear. Adequate for basic use but incomplete for a tool with complex output.

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

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

Schema coverage is 100%, baseline 3. The description adds value by listing required args keys per bundle (e.g., safety_check_base=[address]), which is more concise than the schema's generic args description. This helps the agent understand parameter dependencies.

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 bundles 3-5 Onyx tools into one paid call at a discount, listing specific predefined workflows. This distinguishes it from individual sibling tools like onyx_base_token_risk_scan or onyx_base_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?

The description implies usage when running a set of related tools together to save cost, and contrasts with individual calls via 'single x402 settlement vs N separate'. No explicit 'when not to use', 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 are provided, so the description carries the full burden. It thoroughly explains the tool's behavior: fetching verified source, running static vulnerability detectors (listing examples), flagging live on-chain risks, optional deep pass, output format (ALLOW/REVIEW/BLOCK + score), and signing of findings. It also discloses pricing and tier. This is highly transparent.

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

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

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

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

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

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

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the overall audit process but does not significantly enhance parameter semantics beyond what the schema already provides. The description for the 'deep' parameter is essentially repeated from the schema. No additional constraints or formatting details are added.

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

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

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

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

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

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

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

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

No annotations are provided, so the description carries the full burden. It discloses that results come from stdlib's DNS resolver with 20-100ms latency and includes pricing (USDC cost and metered tier). It does not detail error handling (e.g., NXDOMAIN) or TTL behavior, but the disclosed traits are sufficient for typical 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?

The description is three sentences: core action, use cases, and technical details. Every sentence adds value without redundancy. It is front-loaded with the essential 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 single parameter and no output schema, the description adequately explains the return information (IPv4, IPv6, hostname, resolution time) and the backend (stdlib). This is complete for a straightforward DNS lookup 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 host parameter is fully described in the schema (domain or IP). The description adds the critical semantic that the tool behaves differently based on input type—forward or reverse resolution—which the schema's 'description' field alone does not convey.

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 resolves a domain to A/AAAA records or reverse-resolves an IP to its hostname. The specific verb-resource pair and dual functionality distinguish it from numerous sibling tools like whois, url_parse, or ip_geolocate.

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 lists concrete use cases (validating domain existence, infrastructure sharing, CDN mapping, safety lookups) that help an agent decide when to use this tool. It does not explicitly exclude alternatives or state when not to use it, but the context is clear.

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

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

No annotations provided, but the description thoroughly discloses all behavioral traits: three validation steps, typical latency (30-80ms), cost ($0.002 USDC), tier (metered), and return type (confidence verdict plus signals). 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?

The description is four sentences, front-loaded with purpose, followed by details, usage guidance, and performance/cost. No unnecessary words.

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

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

Given the single parameter, no output schema, and low complexity, the description covers all needed information: what it does, when to use, performance, cost, and return type. 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% (one parameter described as 'Address to validate'). The description adds context about validation steps but does not enhance parameter meaning 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 validates email addresses with three specific checks (RFC-5322 syntax, DNS resolution, disposable-provider detection) and returns a confidence verdict and signals. It stands out among siblings like whois or DNS lookup by focusing specifically on email validation.

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

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

The description explicitly suggests using before mailing list signups, password-reset flows, or sales-lead capture. While it doesn't list alternatives or when not to use, 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 the description carries the full burden. It discloses the API used (public ensideas), no key required, typical latency (200-500ms), cost ($0.002 USDC, tier metered), and that it returns canonical address, avatar, and resolver. It does not describe error cases or edge conditions, but given the simplicity of a lookup, it is sufficiently 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 (two sentences plus parenthetical details) and front-loaded with the main purpose. Every sentence adds value: the first sentence states the action and returns, the second gives use case and API characteristics, and the parenthetical includes latency and cost without clutter.

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 simplicity of the tool (one parameter, no output schema), the description covers purpose, usage context, return values, API source, latency, and cost. It does not explain possible errors or the reverse resolution format, but it is adequate for most agent usage.

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

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

Schema description coverage is 100%, so baseline is 3. The tool description does not add significant meaning beyond the schema; it only restates that the parameter accepts an ENS name or address. The schema already documents the parameter well.

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

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

The description clearly states the verb 'resolve', the resource 'ENS name', and the bidirectional capability (to address or vice versa). It specifies return values (canonical address, avatar URL, resolver). There are no sibling tools with similar functionality, so it is well-distinguished.

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 when to use: 'when an agent encounters a human-readable name like vitalik.eth and needs to send funds or validate identity.' It also provides context on the API source and rate limits. However, it does not mention when not to use or alternative tools, though none exist in the sibling list.

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?

Since no annotations are provided, the description carries full burden. It discloses the data source (open.er-api.com, free tier), approximate latency (150-400ms), demo mode behavior (returns USD-EUR @ 0.92), and pricing ($0.002 USDC, metered tier). This provides adequate transparency without 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?

The description is a single paragraph that front-loads core functionality, then provides use cases, technical details, and pricing. Every sentence adds value: currency list, rate details, use cases, data source, latency, demo mode, pricing. It is structured logically but could be slightly more concise by removing redundant phrases like 'convert between any two fiat currencies' (implied by the title).

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 3 params (2 required), no output schema, and no annotations, the description provides sufficient context: what it does, when to use, technical details, demo behavior, and pricing. It covers the essential aspects for an agent to invoke it correctly. However, it does not specify whether the rate is real-time or cached, which might be relevant.

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

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

The schema describes two of three parameters ('from', 'to' with ISO-4217 descriptions), covering 67%. The description adds context by listing examples and specifying the source as 'current mid-market rate'. It clarifies that 'amount' defaults to 1, which is helpful. The description compensates for the missing schema description on 'amount' by implying its purpose.

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 conversion between fiat currencies, lists multiple examples (USD, EUR, GBP, JPY, BRL, 160+ ISO-4217 codes), and specifies the result includes rate, converted amount, and timestamp. It distinguishes itself from sibling tools by focusing specifically on fiat conversion, which no other sibling appears to cover.

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 three use cases: pricing a service, normalizing multi-currency invoices, and converting x402 USDC for human-readable receipts. It also mentions demo mode for testing. However, it lacks explicit guidance on when not to use this tool, such as for cryptocurrency conversion (likely handled by other onyx 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 carries full burden. It discloses that the tool uses a real regional vantage, never guesses, and includes pricing ($0.25 USDC, metered). It doesn't cover authorization or rate limits, but the key behavioral aspects are transparent. No contradiction with annotations.

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

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

The description is concise (about 70 words), front-loaded with the core purpose, and structured efficiently. It lists inputs and outputs in a clear, scannable way without any 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?

Despite no output schema, the description provides a comprehensive overview of what the tool returns (final URL, price, currency, geo-block, language, divergence flags). The tool's complexity is moderate, and the description is sufficient for understanding its capabilities and limitations.

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

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

Schema coverage is 100% with clear parameter descriptions. The tool description reinforces the purpose of each parameter but doesn't add significant new meaning beyond the schema. Baseline score of 3 is appropriate given the schema already explains them well.

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

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

The description clearly states the tool's purpose as a 'Geo ground-truth oracle' and details its specific function: observe a URL from a real regional vantage to get final URL, price, currency, geo-block status, language, and divergence flags. This distinguishes it from any sibling tools, none of which serve a similar geo-verification 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 explains when to use the tool (to detect region-gating missed by datacenter-IP agents) and what inputs are needed (URL with optional expectations). It implies it's for verifying geo-specific behavior but doesn't explicitly state when not to use it or list alternatives. However, the context is clear enough for an agent to decide.

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

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

With no annotations, the description carries full burden. It discloses the tool runs locally, never logs input, and executes in <2ms. Pricing and tier are provided. No side effects or destructive actions are relevant. This is transparent for a compute 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 extremely concise: two sentences plus a parenthetical with price and tier. Each sentence earns its place—first states the operation, second explains output and use cases, third gives operational context. 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 tool's simplicity, the description is complete. It lists all hash algorithms, input types, output format (hex and base64), use cases, performance, and cost. No output schema is provided, but the return value explanation 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 both parameters described. The description adds context by clarifying that input can be text or base64-encoded bytes, and that both parameters are optional. This adds meaning beyond the schema.

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

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

Description explicitly states the tool computes multiple hash algorithms (md5, sha1, sha256, sha512, sha3-256) on text or base64 bytes. This is a specific verb-resource combination that clearly differentiates from sibling tools, none of which are hashing-focused.

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?

Description provides explicit use cases: content-addressed lookups, dedupe keys, signature verification support, fingerprinting. Also includes performance characteristics (local, fast, cheap). However, it does not explicitly state when not to use or mention alternatives, leaving some room for ambiguity.

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

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

No annotations provided, but description discloses performance (150-500ms) and cost ($0.002 USDC). States the output is stripped of HTML noise. Adequate transparency for a read-only fetch 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?

Concise and well-structured: main action first, then specific tags, then use cases, then performance 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 description is complete for the tool's purpose: it explains what it does, what it extracts, when to use, and performance/cost. No gaps given the single parameter and lack of 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?

Only one parameter 'url' with schema description 'URL to inspect'. Schema coverage is 100%, so baseline is 3. The tool description does not add additional semantics beyond the schema, but the overall purpose is clear.

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 fetches a URL and extracts specific meta tags (OpenGraph, Twitter Card, standard). It distinguishes from sibling tools by specifying the exact tags and use cases like previewing links or detecting spam.

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 lists use cases: 'Use when an agent needs to preview a link before sharing, build a citation card, or detect spam/ads via meta-tag fingerprints.' No explicit when-not-to-use, but the context is clear enough.

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

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

The description fully compensates for missing annotations by disclosing the backend (ip-api.com), rate limit (~1k requests/min), typical latency (80-200ms), demo mode behavior, and pricing ($0.002 USDC). 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?

The description is dense but well-structured, covering purpose, returns, use cases, backend, and pricing in four sentences. It is efficient without being overly verbose.

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 schema (one parameter, no output schema), the description is complete. It lists all returned fields and provides behavioral context (rate limits, demo mode, pricing), leaving no significant gaps.

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

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

Schema coverage is 100% for the single parameter. The description adds minimal extra meaning (e.g., 'public IPv4/IPv6' vs. schema's 'IPv4 or IPv6 address'), 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 geolocates public IP addresses and enumerates the specific data returned (country, region, city, lat/lon, timezone, ISP, ASN, flags). It distinguishes itself from sibling tools like `onyx_geo_verify` by focusing on IP-based 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 specific use cases (filtering traffic, fraud scoring, routing) and mentions demo mode for testing. However, it does not explicitly state when not to use this tool or compare it to alternatives, which 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?

With no annotations, description adds important behavioral context: stdlib-only, runs locally, never sends token anywhere, and includes pricing/tier. Could mention error handling for malformed tokens.

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

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

Two sentences, front-loaded with purpose, no superfluous words. Efficient and clear.

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, description explains what is returned (header, payload, claims, validity) and includes price and tier. Sufficient for agent to use 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?

Only one parameter with 100% schema coverage. Description does not add new meaning beyond schema; schema already adequately describes the parameter. Baseline score of 3.

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

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

Description clearly states the tool decodes a JWT without verifying signature, lists specific returned data (algorithm, key id, claims, expiry status, anomalies), and distinguishes from 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?

Explicitly states when to use: when inspecting a token from an external API for routing, expiry, or audit logging. Does not explicitly mention alternatives or when not to use, 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?

With no annotations, the description carries full burden. It discloses that it calls the Onyx Protocol verifier, returns ok, scope, spend cap, issuer, revocation status, and mentions the price and tier. This is detailed and helps the agent understand side effects and dependencies.

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, each serving a distinct purpose: what it does, what to pass and what to expect, and when to use it. No filler or repetition.

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

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

Given the tool's simplicity (one param, no output schema, no annotations), the description covers all necessary aspects: purpose, input example, output details, use cases, and even pricing. No gaps.

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

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

Schema coverage is 100% with a single parameter. Description adds value beyond schema by providing an example credential id and explaining what the function returns. This enhances understanding of the parameter's purpose.

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

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

Description clearly states the tool verifies an Onyx Protocol KYA credential, provides a concrete example, and lists the return fields. It distinguishes itself from sibling tools like onyx_agent_audit_trail or onyx_verify_explain by focusing on credential 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?

Explicitly states use cases: gating paid tool access, auditing agent operations, composing with x402 settlement. Lacks explicit exclusions or alternatives, but the context provided is sufficient for an AI to decide when to invoke.

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. The description mentions the cost ('$0.02 USDC, tier: metered') but does not disclose read-only status, potential side effects, data freshness, or rate limits. For a snapshot tool, these omissions leave significant behavioral uncertainty.

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 paragraph that front-loads the purpose. It is concise (no filler), with clear declarative sentences. The marketing tagline ('Bloomberg-terminal for the agentic economy') is acceptable for context.

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

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

Given no output schema, the description enumerates key outputs (top services, blue-ocean niches, saturated niches, pricing audit, per-network split). It is mostly complete for a snapshot tool, though the exact return format or data structure is not explained, leaving some 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?

Parameter descriptions in the input schema already cover semantics (e.g., 'Optional candidate capability tokens', 'If true, include the Onyx pricing audit'). The main description adds no new parameter-level detail beyond mentioning 'pricing audit' again. 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 it's a 'One-call market snapshot of the paid x402 MCP economy' and enumerates specific outputs (CDP visibility, blue-ocean niches, saturated niches, pricing audit, per-network split). It distinguishes itself from siblings like 'onyx_bazaar_blue_ocean' and 'onyx_bazaar_compare' by offering a comprehensive overview.

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 use cases: 'competitive intel, pricing decisions, niche selection.' However, it does not provide when-not-to-use guidance or mention alternative tools for more specific queries (e.g., onyx_bazaar_blue_ocean for focused blue-ocean analysis).

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?

Describes scoring factors (price, freshness, schema match, network preference) and output structure (URL, method, body schema, expected price, payTo, asset, network), which is good given no annotations.

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

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

Information-dense and front-loaded, but contains some marketing language ('FIRST MCP meta-router') that could be trimmed for conciseness.

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

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

Despite no output schema, the description fully explains the return value (top N ranked routes with full call templates), making it complete for 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?

With 100% schema coverage, description adds value by explaining the purpose of capability, max_price_usdc, preferred_network, and include_onyx_routes beyond their 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 is a meta-router that takes a plain-English capability description and returns ranked routes with call templates, distinguishing it from the many specific sibling tools.

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

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

Provides explicit usage example ('Describe a capability in plain English') and implies use when needing to find/compare MCP tools, but lacks explicit 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?

The description explicitly discloses that the tool provides raw observations, never asserts legitimacy or scam, and that outputs are Ed25519-signed to prove genuineness and integrity. It also mentions the cost ($0.25 USDC) and tier. With no annotations provided, the description fully carries the burden of behavioral transparency.

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

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

The description is concise at around 125 words and front-loads the tool's purpose. It lists the output fields efficiently. However, it could be slightly shorter without losing clarity, and the structure is logical.

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

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

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

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

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

Schema description coverage is 100%, so the baseline is 3. The description briefly restates the parameters ('domain, optionally the brand and expected price') but does not add significant meaning beyond what the schema already provides. The schema itself gives examples and explains parameter effects well.

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

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

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

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

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

The description implies usage before checkout to verify merchant facts, but it does not explicitly state when to use this tool versus alternatives. There is no guidance on when not to use it or mention of other related tools such as onyx_fact_check or onyx_retail_price_check. The context is clear but lacks exclusion criteria.

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

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

Describes return fields but does not mention read-only nature (no annotations), error handling, or data freshness. Since annotations are absent, more detail on behavior 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?

Three concise sentences, front-loaded with action and key details. 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?

Provides return structure, use cases, and pricing. Lacks explanation of error conditions or data recency, but overall sufficient for a simple lookup 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 covers 100% of parameter description. Description repeats schema content without adding new semantics beyond use context. Baseline 3 with high 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?

Description clearly states it looks up the OAI score for an agent identity, specifying input types (DID or wallet address) and output components (composite score, breakdown, timestamp). It is distinct from sibling tools like onyx_agent_id or onyx_agent_audit_trail.

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 use cases: trust-tier gating, routing decisions, partnership vetting. Does not provide when-not-to-use or alternatives, which is acceptable given the focused purpose.

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

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

With no annotations, the description carries full burden. It discloses key behaviors: Ed25519 signature verification, logging verdict->outcome to a public ledger, and requiring the signed_verdict to contain an onyx_attestation block. It does not mention rate limits or error handling, but core behavior is covered.

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

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

The description is front-loaded with the main action and includes necessary details, but has some marketing fluff (e.g., 'the only x402 security layer with proven precision'). Overall, it is well-structured and each sentence contributes 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 does not specify what the tool returns (e.g., confirmation, ledger hash). It mentions the ledger behind onyx_track_record as context, but missing return value and error handling information, which is a gap given 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 coverage is 100%, but the description adds context: explaining the purpose of signed_verdict (must contain attestation), the meaning of outcome (actual result), and the optionality of detail and tx_hash. This 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 clearly states the tool's purpose: reporting what actually happened after an Onyx verdict, closing the loop from signed opinions to measured track record. It specifies the verb 'report', the resource (outcome after verdict), and the process, distinguishing it from sibling tools which focus on other Onyx operations.

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 after a verdict is issued, requiring a signed verdict and an outcome. While it does not explicitly exclude alternative tools, its unique function (feedback loop) is clear. The mention of being free is a minor guideline but not extensive.

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 carries burden. It details the output structure and includes pricing info ($0.03 USDC) and tier, adding valuable behavioral context beyond the schema. Discloses synthesis behavior and output components.

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?

Extremely concise: one sentence covers input, output, and composition order. Every word serves a purpose; 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?

No output schema, so description provides necessary return details (metadata, thematic overlap, citation graph, summary). Specifies constraints (2-10 papers). Lacks error handling details but is otherwise thorough.

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 schema description explains the 'ids' parameter. The tool description adds value by explaining the output structure and purpose, but the parameter itself is well-documented in the schema.

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

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

The description specifies a clear verb ('Structured synthesis') and resource ('N academic papers'), distinctly differentiating it from sibling tools like onyx_research_intel by noting it composes after that tool.

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

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

Explicitly states 'Composes after onyx_research_intel', providing clear guidance on when to use this tool in a workflow. No explicit when-not-to-use or alternatives, but the context is sufficient.

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

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

With no annotations, the description carries full burden. It transparently lists the data sources probed (domain, CDP, awesome-mcp, GitHub) and the output (gap analysis, integration angle, signal strength). Also mentions price and tier. Lacks disclosure of side effects or error behavior, but it's a read-only probe, so acceptable.

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

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

The description is concise at 6 sentences, starting with a clear question that sets the context. It front-loads the purpose and output, then adds usage context and pricing. No unnecessary words, though the price information could be seen as secondary.

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 a high-level overview of the return value (gap analysis, integration angle, signal strength). For a tool with multiple probes and a complex output, more detail on the structure or format of the analysis would improve completeness. Still adequate 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?

Schema coverage is 100%, so the schema already documents both parameters. The description adds context by explaining how the 'company' parameter is used (name or domain) and that 'github_org' narrows the probe, but this largely mirrors the schema descriptions. The added context on probing behavior is helpful but not essential.

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: probing a company's stack to find where Onyx fits, returning a gap analysis with integration angle and signal strength. It uses specific verbs ('probes', 'returns') and distinguishes itself from siblings like onyx_research_intel by focusing on partnership contexts.

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 the tool is built for 'outbound partnership / merger / B2B sales conversations,' providing clear context. However, it does not explicitly mention when not to use it or name specific alternatives, though the sibling list implies differentiation.

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

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

No annotations are provided, so the description bears full responsibility. It discloses that the tool is 'Stdlib-only — runs locally, never sends the password anywhere,' and gives performance ('<5ms') and pricing ('$0.001 USDC'). This fully informs the agent of behavioral constraints.

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), front-loads the purpose, and every sentence adds essential information: what it does, what it returns, when to use it, and how it behaves. 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?

Although there is no output schema, the description fully describes the return values (Shannon entropy, character-class diversity, length, common-pattern detection, and a verdict). Combined with the single input parameter, it provides a complete picture of the tool's functionality.

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

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

Schema description coverage is 100% with a single parameter described as 'Password to score'. The description adds no additional semantic meaning beyond the schema, so it meets the baseline but does not enhance understanding further.

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 'Score password strength on a 0-100 scale' and enumerates the return values. It is highly specific and distinct from all sibling tools, which cover domains like blockchain, browser, email, 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 explicitly says 'Use when an agent generates passwords for accounts it creates, or when validating user-supplied credentials.' It provides clear context, though it does not mention when not to use or alternatives. However, no sibling tools perform password strength, so exclusion is unnecessary.

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

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

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

Two sentences with clear, front-loaded purpose. Every sentence adds value and there is no unnecessary information.

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

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

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

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

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

Schema description coverage is 100%, so parameters are well-documented in schema. The description adds context on ranking and fallback but does not significantly enhance parameter meaning beyond what the schema provides.

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

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

The description clearly states the tool's function: 'Research intel — has someone solved X already?' It specifies querying 240M+ academic works via OpenAlex, ranking by citation count, recency, and relevance, and returning top N papers with abstracts, citations, and authors. It distinguishes itself from sibling tools like onyx_paper_synthesis.

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

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

Explicitly states intended use: 'Built for autonomous agents that need to check prior art before burning cycles re-deriving a known result.' Provides context with a fallback mechanism and pricing. Does not explicitly state when not to use, but the context is sufficient.

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

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

No annotations provided, so description carries full burden. It discloses key behaviors: fetches fresh data, never guesses, returns price=None with confidence='none', and provides extraction source. It also mentions cost. However, it does not cover error handling for invalid URLs, rate limits, or authentication needs.

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

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

The description is concise (4 sentences), well-structured: purpose, behavior, usage guidance, cost. Every sentence adds value; no fluff.

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

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

Given no output schema, the description adequately outlines result fields (price, currency, in-stock state, extraction source, matches_expected/drift). For a simple 2-param tool, this is sufficient but could be more explicit about output structure.

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

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

Schema coverage is 100%, so baseline 3. The description adds meaningful context beyond schema: for 'expect_price' it explains the purpose (detect stale/hallucinated quotes) and the returned fields (matches_expected, drift). For 'url' it reinforces the expected usage. This adds value.

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

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

The description clearly states the tool fetches real-time retail prices from product URLs, distinguishing it from siblings like onyx_bazaar_compare by emphasizing 'ground-truth retail oracle' and 'long tail of no-API shops'. The verb+resource+scope are specific and unambiguous.

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

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

The description provides explicit usage guidance: 'Use before an agent quotes, compares, or transacts on a price it would otherwise invent.' It also explains when it returns None. However, it does not explicitly mention alternatives among siblings or when not to use it.

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

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

With no annotations, the description carries the full burden. It discloses that the output is 'SIGNED, web-grounded', 'aggregated public sentiment and cited sources', and that the tool 'attests what was observed, not a trust ruling'. It also mentions pricing and that it is 'Never fabricated'. However, it lacks details on rate limits, error responses, or any destructive side effects, though these are likely not applicable for a read-only oracle.

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

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

The description is concise at 4-5 sentences, each adding unique value. It is front-loaded with the main action and includes pricing and tier as relevant context. There is no wasted content, though it could be slightly more streamlined.

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

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

Given the complexity and the absence of an output schema, the description sufficiently explains the output's nature (signed, web-grounded, aggregated sentiment, cited sources) and the tool's role. It covers input, output, use case, and philosophy. Minor gaps include lack of exact output format or error cases.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it repeats the parameter purposes with examples (e.g., 'shipping speed', 'customer support'). While helpful, it does not significantly enhance understanding 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 specifies the tool's verb ('get a signed, web-grounded read') and resource ('product/business/service' with optional aspect). It distinguishes itself from sibling tools like 'onyx_agent_reputation' by emphasizing that it provides observed evidence ('attests what was observed, not a trust ruling') and is a 'ground-truth oracle'.

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

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

The description explicitly states when to use the tool: 'For an agent about to recommend, buy from, or partner with an entity.' It provides clear context but does not explicitly mention when not to use it or compare to alternatives like 'onyx_fact_check'.

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 exactly what is returned: raw text, matched rule, crawl-delay, and verdict. Also provides latency and pricing details. No annotations exist, so the description fully carries the transparency burden. Missing potential edge cases like errors, but sufficient for this 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, each serving a distinct purpose: purpose, outputs, usage advice. 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?

Given the simplicity of the tool (2 params, no output schema), the description fully covers purpose, inputs, outputs, and usage context. The agent has all necessary information 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 covers 100% of parameters with descriptions. The description adds no additional meaning beyond stating the purpose, so baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Fetch' and 'report' with specific resource 'domain's robots.txt' and outputs. It distinguishes itself from sibling tools by focusing on robots.txt checking, which is unique among the listed 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 says 'Use when an agent does web scraping and wants to be polite' and provides motivation ('saves bans, saves CAPTCHAs, saves drama'). Also includes performance and cost, aiding decision-making.

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

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

With no annotations, the description carries full burden. It discloses key behaviors: returns PASS/REVIEW/FAIL verdict, risk score, take-rate quote; uses Ed25519 signing; Onyx never takes custody; cost is $0.25 USDC. However, it omits idempotency, side effects, or authentication requirements, but provides good overall transparency.

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

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

The description is a single paragraph that conveys necessary information but includes minor marketing fluff ('serious agent', 'full security stack') and pricing details. It is front-loaded with the purpose, but could be more concise.

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

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

Given no output schema, the description adequately explains return values (verdict, risk score, quote) and signing proof. It covers operational context (security stack, no custody, cost). Missing error handling or rate limits, but overall complete for a clearance tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining how optional parameters trigger additional checks (contract audit, reputation). It also clarifies that amount drives risk threshold and take-rate, which goes beyond the schema's descriptions.

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

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

The description clearly states the tool's purpose: 'Secure-transaction RAIL: one signed clearance before an agent sends funds.' It specifies the action of obtaining a security verdict for a payment, distinctively positioning itself among siblings as a pre-payment clearance check. The verb 'Give' plus inputs makes it concrete.

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

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

The description implies usage context ('before moving real money') but does not explicitly state when to use or avoid this tool versus siblings like onyx_approval_guard or onyx_tx_guard. No alternatives or exclusions are mentioned, leaving the agent to infer.

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

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

With no annotations provided, the description fully discloses behavior: it checks for unlimited token-permit values, EOA/unverified spenders, NFT-order signatures, and bad deadlines. It returns a signed ALLOW/REVIEW/BLOCK plus plain-English explanation. It also notes the cost ($0.03 USDC) and that it is a check, not a signing action. This is 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 moderately lengthy but efficient. It is front-loaded with the purpose and context, followed by details of what it checks and returns. Every sentence adds value, though minor trimming could improve conciseness. Overall it is well-structured.

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

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

Given no output schema, the description clearly explains the output format (ALLOW/REVIEW/BLOCK plus explanation). The single input parameter is well-documented in the schema. The description covers the problem domain and expected usage comprehensively, making the tool self-contained.

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

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

Schema coverage is 100% for the single parameter 'typed_data', and the schema already provides a clear description of the expected object structure. The tool description does not add additional meaning beyond what the schema offers, so a 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 it is a pre-signature firewall for EIP-712 typed-data messages, specifying types like Permit, Permit2, and Seaport orders. It explains the tool's function: identifying what a signature authorizes, flagging risks, and returning an ALLOW/REVIEW/BLOCK verdict. This is highly specific and distinguishes it from sibling tools such as onyx_tx_guard or onyx_approval_guard.

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

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

The description explicitly states when to use: before signing an off-chain EIP-712 typed-data message. It contrasts with on-chain tx checks that miss this vector, making the context clear. It does not explicitly name alternatives among siblings, but the description effectively narrows the use case.

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.