AlphaPipeline Agent MCP

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

Annotations already mark this read-only, and the description adds substantial behavioral context: reference price source, assumed flat gas cost, and a clear warning that net_spread_pct excludes DEX swap fees, CEX fees, and slippage. It also discloses payment in USDC on Base, which is beyond what annotations provide.

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

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

Four sentences carry the use case, key outputs, critical caveat, exclusions, and payment details. The critical profitability caveat is placed prominently, and every sentence earns its place.

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

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

The description is complete for a read-only screening tool: it covers inputs, outputs, cost assumptions, fee exclusions, and payment, while the output schema removes the need to describe return values in prose.

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 of 3 applies. The description clarifies the overall model but does not add new meaning to individual parameters beyond the schema's own 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 states a specific purpose: checking whether global reference vs DEX pool price divergence is enough after gas costs, before executing a cross-venue arbitrage trade. It names the exact outputs (gross/net spread percentages, is_profitable) and distinguishes itself from DEX-only depth/contract checks.

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

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

It explicitly says when to use ('before executing a cross-venue arbitrage trade') and when not to use ('DEX-only liquidity depth checks or contract security'). The caveat about fees gives practical guidance on interpreting results correctly before acting.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context beyond that: it is a zero-dependency static calendar with no upstream failure risk, and it is paid in USDC on Base, which informs cost and reliability expectations.

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 use case and exclusions. It is a bit promotional with phrases like '100% uptime' and 'paid in USDC on Base,' but these add decision-relevant reliability and cost context without excessive length.

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 zero parameters, read-only annotations, and an output schema, the description covers all essential aspects: purpose, specific macro events, year scope, exclusions, and reliability/cost characteristics. Nothing critical is missing 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?

There are no input parameters, and the description explicitly confirms this with 'No input parameters.' Since there is nothing for the schema or description to elaborate on, the baseline of 4 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 states a specific verb and resource: it provides days remaining until major US macro events (FOMC, CPI, NFP). It clearly identifies the tool as a static 2026 macro calendar, which differentiates it from the finance, derivatives, and security sibling tools.

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

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

The description explicitly says when to use it: when planning trading schedules around major US macroeconomic volatility. It also explicitly states when not to use it: for real-time market price data or economic forecast consensus figures, which is clear exclusion 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavior beyond that: it performs a pure calculation on top of funding_rate data, has no extra upstream call, flags the funding-paying side, and is paid in USDC on Base. These details are not visible elsewhere.

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 dense, front-loaded sentences cover the main action, exclusions, alternatives, and payment context with zero filler. Every sentence earns its place.

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

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

For a two-parameter calculation tool with an output schema, the description covers purpose, usage boundaries, computation behavior, and payment context. Nothing needed for correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description contextualizes assumed_round_trip_cost_pct as the cost recouped by funding income, but it does not add new parameter-level details beyond what the schema already provides.

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

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

States a specific verb and resource: 'evaluate a spot+perpetual carry trade' and enumerates three concrete outputs: annualized APR, funding side, and days to recoup cost. It also explicitly distinguishes itself from the sibling tool derivatives.funding_rate, making its purpose clear without needing to open schemas.

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?

Contains explicit routing guidance: 'Do not use for the raw current funding rate alone (use derivatives.funding_rate) or for spot price data.' It also clarifies this is a pure calculation with no extra upstream call, which tells the agent exactly when this tool is appropriate versus 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral value beyond that: Bybit primary with Binance fallback, open_interest_usd only existing on the Bybit path and null on Binance, and payment currency on Base. This gives a useful, non-obvious operational picture.

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 carry a use case, data source behavior, exclusions, and payment context with no filler. The structure front-loads the most decision-relevant information and then gives data path details. Slightly dense, but efficient.

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

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

For a simple one-parameter tool with read-only annotations and an output schema, the description captures the key behaviors, source paths, and nullability caveat. It is sufficiently complete for an agent to decide whether to call it and understand the response shape, though it does not explain symbol normalization beyond the schema examples.

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

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

Schema description coverage is 100% and includes examples like 'BTC, ETH, or BTCUSDT,' so the schema already documents the single parameter fully. The tool description adds context about what symbol relates to but does not add much beyond the schema, so the 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 starts with a clear use case ('analyzing perpetual futures funding rates, long/short market sentiment crowding, or timing hedging strategies before settlement periods') and explicitly states the resource: Bybit/Binance perpetual funding rates plus mark_price/index_price and open_interest_usd. It also names what it is not for ('spot market volume or token security checks'), 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?

The description gives explicit when-to-use instructions tied to concrete market conditions, and explicit negative guidance for spot volume and token security. It does not name any specific sibling tool to switch to, so routing is slightly weaker than the highest bar, but the exclusions are 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this by using 'audit' and describing read-only data retrieval. It adds value by clarifying that risk_flags come from fixed numeric thresholds (not heuristics), that max_leverage and return_on_equity_pct are Hyperliquid's own reported fields, and that the service is paid in USDC on Base. These details go beyond the annotations and give the agent a fuller picture of the tool's behavior and cost implications.

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

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

The description is information-dense and well-structured, front-loading the core purpose ('Use this tool to audit a Hyperliquid wallet address') before diving into details. Every sentence contributes meaning: it lists output fields, clarifies provenance, states exclusions, mentions the lack of a leaderboard, and notes payment. While it is relatively long, the complexity of the tool justifies the length, and there is no redundant 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 that the tool has a single parameter, a clear output schema (as indicated by 'Has output schema: true'), and read-only annotations, the description covers all the essential context an agent needs: what the tool does, what it returns, its limitations, what it does not do, and the cost model. It fully equips an agent to decide when and how to 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?

The schema coverage is 100% for the single parameter, and the schema already describes it as 'Hyperliquid/EVM wallet address to audit (0x...).' The description adds minimal additional semantic value beyond the schema, such as confirming the address must be one the user already knows. Since the schema does the heavy lifting, a 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 action ('audit'), the resource ('Hyperliquid wallet address'), and enumerates exactly what is returned (side, size, leverage, etc.). It also explicitly distinguishes itself from discovering or ranking smart money wallets, which differentiates it from potential sibling tools. The phrase 'you already know' clarifies that it only audits a supplied address, leaving no ambiguity about its function.

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

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

It explicitly states when to use it ('audit a Hyperliquid wallet address you already know') and when not to ('Do not use for spot price data or any exchange other than Hyperliquid'). It also explains that it cannot discover smart money wallets because Hyperliquid's API has no such endpoint, preventing misuse. These explicit exclusions and context make the usage boundaries crystal 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is a safe read operation. The description adds valuable behavioral context: it's GeckoTerminal-backed, uses constant-product slippage estimation, and includes a slippage_tiers array for quick depth assessment without extra calls. It also mentions the payment requirement. This exceeds the baseline set by 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 two sentences with no wasted words. The first sentence states the core purpose, and the second adds key details (GeckoTerminal-backed, slippage tiers, exclusions, payment) in a compact manner. It is front-loaded and each clause earns its place.

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

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

The presence of an output schema covers return values, and the description explicitly mentions the slippage_tiers output array. It also notes the cost and exclusions. It does not mention network defaults or how pool/token selection works, but those are covered in the schema. For a tool with multiple parameters and a clear purpose, this is nearly complete, missing only minor edge-case details.

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 all four parameters are fully documented in the schema. The description does not add any parameter-specific semantics beyond referencing trade_size_usd in the main text. Per the rubric, a baseline of 3 is correct when the schema carries the full parameter documentation burden.

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 calculates DEX price slippage, pool liquidity depth, and optimal routing, naming the specific resource (GeckoTerminal-backed pool analytics) and action. It differentiates from CEX tools by explicitly saying 'Do not use for centralized exchange (CEX) orderbooks,' which distinguishes it from any potential 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?

It provides explicit when-to-use guidance ('before executing an on-chain token swap') and explicit exclusions ('Do not use for centralized exchange (CEX) orderbooks or contract risk analysis'). It also notes a cost implication ('Paid in USDC on Base'), which helps agents decide whether to invoke it. This is strong usage direction.

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?

Annotations only state readOnlyHint and destructiveHint. The description goes far beyond that by disclosing the real-time data sources (Upbit vs Coinbase with CoinGecko fallback), explicitly warning it is NOT a live Binance orderbook despite the legacy field name, mentioning reverse-premium and surge alerts, and stating the payment model (USDC on Base, free while flag is false). This is rich behavioral context that helps the agent set expectations.

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 efficient, using multiple clauses to pack critical information without fluff. It leads with the usage context, then details data source, alerts, and payment. It is slightly long but every sentence contributes value, 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's complexity (arbitrage, multiple alerts, payment, data sources), the description covers all essential aspects: when to use, data sources, fallback, exclusions, and cost. An output schema exists, so return-value details are not needed. Nothing an agent requires to decide whether to call it and what to expect is missing.

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

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

The only parameter (symbol) has full schema coverage (100%) with its own description, so the baseline is 3. The tool description adds only a default value (BTC) but no additional semantic nuance beyond what the schema provides. It does not explain symbol format or edge cases, but the schema covers it adequately.

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

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

The description opens with a precise verb-resource pair: 'evaluating Korean exchange price premiums,' and enumerates specific use cases (kimchi premium, Upbit vs global reference, arbitrage, Korea-specific anomalies). It explicitly distinguishes itself from a Binance orderbook and general spot prices, which differentiates it from siblings like arb.spread_matrix or derivatives.funding_rate.

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 when-to-use guidance ('Use this tool when evaluating...') and explicit exclusions ('Do not use for general USD spot prices or on-chain DEX swaps'). It does not name a specific alternative tool, but the when-not cases are stated unambiguously, which is sufficient for routing.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context: it is a live snapshot (not historical), it returns book_snapshot_time and tick_size/min_order_size, and it notes payment in USDC on Base. There is 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 moderately long but every sentence earns its place: purpose, scope, return fields, input modes, and an explicit exclusion. It is front-loaded with the main purpose and structured logically, with no filler 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?

Given the tool's complexity (5 parameters, resolution logic, live snapshot behavior) and the presence of an output schema, the description is remarkably complete. It covers input alternatives, output fields, edge cases (null tick_size), and the key limitation (no fuzzy slug matching). Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the relationship between market_slug and token_id (automatic resolution) and clarifying that outcome is only used with market_slug. This goes beyond simple parameter definitions and helps an agent understand how to pass inputs correctly.

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

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

The description states a specific verb (walk/audit) and resource (single Polymarket outcome's live order book) and precisely defines what it returns (fillable size, average price, price impact vs best quote). It explicitly contrasts with a sibling tool (prediction.neg_risk_arbitrage) for multi-outcome basket arbitrage, making its scope 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?

It clearly explains when to use: for a live liquidity snapshot of a single outcome, and explicitly says 'Do not use for multi-outcome basket arbitrage detection (use prediction.neg_risk_arbitrage instead)'. It also specifies input modes (raw token_id or exact market_slug) and the exact-slug requirement, giving an agent full decision 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?

The annotations declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe, read-only operation. The description goes beyond annotations by explaining the practical caveats: the capacity notional is priced at top-of-book (optimistic), so the agent should use vwap notional for realistic fill cost; and the oldest_book_snapshot_time indicates staleness bottleneck. This is valuable operational context that helps the agent interpret results correctly and avoid misusing the data. Slightly not a 5 because it doesn't disclose the exact return format, but the output schema exists and the caveats are rich.

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

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

The description is moderately concise but informational. It front-loads the core purpose in the first sentence, then adds critical caveats about capacity pricing and staleness, and ends with platform restrictions. It is longer than ideal but every sentence adds value—no filler. The structure is logical: purpose → outputs with caveats → usage restriction. It earns a 4 rather than a 5 because it is somewhat dense and could be split into more digestible parts, but it is not 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 tool's complexity (4 parameters, output schema, varying market types), the description is complete. It explains the core arbitrage concept, tells the agent precisely when to use it and when not, and clarifies the meaning of key outputs (capacity, vwap, staleness). The output schema likely details return fields, so the description doesn't need to repeat that. The platform restrictions (Polymarket, no Kalshi) are essential for correct usage, and they are included. The description is fully adequate for an agent to call the tool correctly.

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

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

The input schema already has 100% description coverage, with each parameter (event_slug, max_slippage_pct, min_net_edge_pct, assumed_round_trip_cost_pct) clearly described. The description adds extra semantic meaning by explaining the context of these parameters: e.g., max_slippage_pct is for 'sizing capacity' and min_net_edge_pct relates to flagging 'arbitrage_viable', and assumed_round_trip_cost_pct is a buffer. This goes beyond the schema's generic descriptions, adding operational insight (e.g., these are all percentages relative to basket notional).

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: detects basket arbitrage in Polymarket neg-risk events. It specifies the resource (basket of all outcomes in a mutually-exclusive market), the verb (detect), and the key mechanism (full YES basket settles to $1, so deviation from $1 is an edge). It also distinguishes itself from many siblings: it explicitly notes 'Polymarket only' and 'Do not use for binary Yes/No markets' or Kalshi, which differentiates it from other prediction-market or security tools in the list.

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 Polymarket neg-risk events with multiple outcomes where a full YES basket can be constructed. It also states when NOT to use it: for binary Yes/No markets (no basket to arbitrage) and for Kalshi (Data ToS forbids it). This is clear, specific guidance that helps an agent select the right tool without needing to infer from context. It also hints at how to use the results (using vwap notional for realistic fills).

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?

Annotations already declare readOnlyHint=true, but the description adds valuable behavioral context: it reuses GoPlus data without an extra upstream call, outputs only GoPlus's lock/burn numbers with no qualitative judgment, and is paid in USDC on Base. These details go beyond the structured fields and enrich the agent's understanding of side effects and 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 front-loaded with the core purpose in the first sentence, followed by relevant technical details, exclusions, and cost. Every sentence contributes unique information with no fluff or repetition, making it efficient and easy to scan.

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

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

With an output schema present and read-only annotations, the description covers the essential context: purpose, input semantics, data source, output category, exclusions, and payment. It is fully self-contained for an agent to select and invoke the tool correctly, especially given the sibling differentiation.

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%, with both chain_id and contract_address clearly described. The description does not add parameter-specific meaning beyond the schema, which is acceptable given the high schema coverage; the baseline of 3 applies.

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

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

The description clearly states the tool's function: checking whether a token's liquidity pool is locked, burned, or held by a single wallet, and categorizes it as a rug-pull signal. It explicitly distinguishes itself from sibling security.token_risk by noting that token_risk does not cover this check, making the specific resource and verb unmistakable.

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 when-to-use guidance ('before trusting its liquidity') and exclusion criteria ('Do not use for honeypot or tax checks (use security.token_risk) or market price data'). Names the alternative tool and the conditions that route to it, leaving no ambiguity for the agent.

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

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

Discloses significant behavior beyond annotations: runs in parallel, returns both underlying results, dedupes risk_flags, provides risk_flags_count, deliberately does not compute composite score, copies fields unchanged, cheaper than separate calls, and mentions payment in USDC on Base. No contradiction with readOnlyHint/destructiveHint.

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 thorough but not wasteful; every sentence contributes value (purpose, behavior, exclusions, cost). It's front-loaded with the primary use case. However, it is slightly long for a tool description, though justified given the composite nature.

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

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

With an output schema present, return structure is covered. The description covers behavior, cost implications, exclusions, and payment details, making it complete for an agent to decide when to use it and what to expect. No critical missing context.

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

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

Schema description coverage is 100%, so both chain_id and contract_address are already well-documented in the schema. The description adds no additional parameter semantics beyond the schema, only implicit reference via the composite nature. 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 states a specific verb 'runs... combined security check' and resource 'token_diagnostic'. It clearly distinguishes from siblings by naming the two underlying tools (security.token_risk and security.contract_health_audit) and explains it returns both plus deduped flags, making its unique function obvious.

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: 'right before buying or swapping an unfamiliar token... when you need a single-call combined security check'. Provides clear exclusions: 'Do not use for token unlock/vesting risk (use unlocks.dump_risk) or if you only need one of the two checks (call that tool directly and pay less).' Names alternatives directly.

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?

Beyond the readOnlyHint and destructiveHint annotations, the description discloses substantial behavioral details: which GoPlus signals are surfaced as risk_flags, that is_proxy/trading_cooldown are informational-only, that fields become null on the Honeypot.is fallback path, and that there is a cost model ('Paid in USDC on Base'). This is far more transparency than the annotations alone could provide.

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

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

The description is long but dense, and each clause adds useful information: usage timing, source, risk signals, fallback behavior, exclusions, and payment. It is front-loaded with the core purpose and then layers supporting details, so it is structured effectively despite its length.

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 that the schema fully documents the two parameters and an output schema is present, the description covers the remaining context: when to use it, what signals to expect, fallback behavior, and cost. Nothing necessary for an agent needs to correctly invoke the tool 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?

Both parameters are already fully described in the input schema with clear descriptions and an example (chain_id, contract_address). The tool description does not add much parameter-level meaning beyond restating that the contract address is an ERC-20 token, so 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's purpose: verify if an ERC-20 contract is a honeypot, rug-pull risk, or has malicious taxes/mintability backdoors, using GoPlus/Honeypot.is. It is specific and actionable, and the mention of 'beyond is_honeypot' and individual risk signals helps characterize its scope. It does not explicitly differentiate itself from sibling security tools like security.contract_health_audit or security.token_diagnostic.

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

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

The description gives a clear when-to-use instruction: 'Use this tool before executing any on-chain swap' and also provides a when-not-to-use constraint: 'Do not use for market price discovery or liquidity depth.' However, it does not name any alternative sibling tools or explain when one of those should be chosen instead.

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?

Annotations already mark the tool as read-only and non-destructive, and the description adds genuinely useful behavioral context beyond that: it converts pages to Markdown, filters boilerplate, and crucially discloses that the tool is paid in USDC on Base. The payment disclosure is important for an agent deciding whether invocation has cost implications. No contradiction with annotations exists.

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: three sentences cover use case, output, exclusions, and payment. It is front-loaded with the primary trigger condition. Minor redundancy exists between 'without wasting context tokens on... boilerplate' and 'optimized for LLM context windows', but no sentence is wasted.

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 provides enough context for an agent to select and invoke the tool correctly: purpose, target URLs, exclusions, parameter format, and cost. The presence of an output schema means return-value documentation is handled elsewhere. It does not discuss rate limits or edge cases like JavaScript-heavy or authenticated pages, but this is not a critical gap for a simple single-URL converter.

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 only one parameter and 100% schema description coverage, the schema already documents the url parameter thoroughly ('Full http(s) URL of the webpage to convert to Markdown'). The tool description restates the general conversion behavior but adds little new parameter-level detail beyond the schema. A baseline score of 3 is appropriate because the schema carries the burden.

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

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

The description uses specific verbs ('parse', 'converts') and clearly identifies the resource: any URL becomes clean Markdown optimized for LLM context windows. The explicit mention of stripping ads, scripts, navigation, and boilerplate distinguishes it clearly from generic fetchers or URL tools. There is no ambiguity about what the tool accomplishes.

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 parsing clean webpage article content or preparing a URL for summarization. It also gives clear negative guidance by warning against raw API endpoints and binary files such as PDFs and images. These when/when-not signals are sufficient, especially since none of the sibling tools overlap with this 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?

Beyond the readOnly/destructive annotations, the description discloses default data source configuration, null-field semantics, missing classification/timing limitations, vesting progress fields, and cost/payment behavior. It also clarifies that null means 'unknown', not 'no risk', which is essential for correct interpretation.

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 and front-loaded with the core purpose, and the later caveats are materially important to avoid misinterpretation. It is longer than minimal, but almost every clause adds safety or correctness context; only the payment detail is somewhat 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?

For a no-parameter tool with an output schema, the description is remarkably complete: it covers use cases, exclusions, data-source limitations, null semantics, required response-field checks, and cost. An agent has enough context to select and invoke this tool correctly without further inference.

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

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

The input schema has no parameters principal, so there is little for the description to add. Per the zero-parameter baseline this is adequate, since no parameter meanings need clarification.

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

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

The description states a specific verb ('evaluate') and resource ('token unlock/vesting supply overhang risk'), and specifies that it returns tokens with risk_level. It also delimits the use case to mid-to-long term positions, but it does not explicitly name sibling alternatives, so it earns a 4 rather than 5.

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

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

It gives clear when-to-use context ('before taking mid-to-long term positions') and explicit when-not-to-use guidance ('Do not use for intra-day slippage or real-time transaction simulation'). It also instructs the agent to check coverage_notice, but it does not point to alternative sibling tools for those excluded use cases.

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