mcp-server

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

Describes key checks (honeypots, rug pulls, ownership, tax manipulation) and return values (risk scores, flags, verdict). Without annotations, it adequately communicates safe read-only behavior, though not explicitly stated.

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 concise sentences that front-load the purpose, then provide details and use case. 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 complexity and presence of an output schema, the description covers essential aspects: purpose, checks performed, return summary, and usage guidance. 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?

Only parameter pool_address is described in context as the address of the pool. Schema coverage is 0%, but the description compensates by clarifying what the parameter should contain.

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 tool performs risk assessment on Aerodrome DEX pool on Base, checking for honeypots, rug pulls, etc. Differentiates from sibling tools like token_due_diligence and contract_check by specifying scope and platform.

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 providing liquidity,' providing clear context. Does not list alternatives or when not to use, but the specificity of Aerodrome DEX on Base implies appropriate usage.

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 mentions a 6-month trend, but does not disclose data frequency, sources, update cadence, or any limitations. Since no annotations are provided, the description carries the full burden, but it remains minimal.

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, efficient sentence that lists the commodities and key feature (6-month trend). No redundant or missing 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 tool is simple with no parameters and has an output schema to detail return values. The description adequately describes the purpose and scope, though it could mention error handling or data availability for 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?

There are no parameters, so the schema covers everything. The description adds context by listing the specific commodities and mentioning the trend, which helps the agent understand the data scope beyond an empty 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 specifies the tool returns global agricultural commodity prices for a defined list (corn, wheat, etc.) and includes a 6-month trend. This distinguishes it from sibling tools that cover other markets (e.g., industrial_metals, energy_markets).

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 obtaining agricultural commodity price data, but it does not provide explicit guidance on when to use it versus alternatives or when not to use it. No exclusions or prerequisites are stated.

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

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

No annotations provided, so description carries full burden. It discloses the scanning scope (first 3 blocks), outputs, and purpose. Does not mention side effects or permissions, but as a read-only analysis tool, it is reasonably 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?

Three sentences, front-loaded with purpose, then method, then usage. Every sentence adds value with no 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?

Covers purpose, method, usage, and outputs. Has output schema, so return value details are not needed. Minor gap: parameter format not described, but overall complete for a single-parameter tool.

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

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

Schema coverage is 0%, so description must compensate. It has one parameter 'address' but does not specify expected format or type (e.g., token contract address). The description implies it is a token address but lacks explicit guidance.

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 detects bundles and snipers for token launches on Base, specifying actions (scans first 3 blocks) and outputs (risk score, bundle wallets, dump status). It distinguishes from most siblings, though a sibling 'token_launches' exists but is not explicitly differentiated.

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 before buying any new token to check if the launch was bundled,' providing a clear usage scenario. However, it does not specify when not to use or mention alternatives.

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

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

Since no annotations are present, the description carries the full burden. It details all return values: risk score 1-10, USD exposure at 5/10/20% drops, and an AI narrative. No side effects are implied, so transparency 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?

Extremely concise: two sentences. First sentence defines purpose and scope, second lists exact outputs. No redundant words.

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

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

Given no parameters and an output schema, the description covers all necessary aspects: purpose, target protocol, specific outputs, and utility for systemic risk assessment. It is fully 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?

Tool has zero parameters, baseline 4. Description adds no parameter info because none exist, and schema coverage is 100%. The description meaningfully explains what the tool does 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?

Purpose is explicit: 'DeFi liquidation cascade risk monitor' tracking collateral-at-risk curves on Morpho Blue markets. It clearly distinguishes from siblings like 'defi_risk' or 'liquidations' by naming the specific protocol and risk type.

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?

States it is 'Critical for assessing systemic DeFi risk,' providing clear context. However, it does not explicitly contrast with alternatives such as 'defi_risk' or 'liquidations', so the guidance is good but not exhaustive.

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

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

No annotations are provided, so the description carries the full burden. It mentions a 15-minute refresh interval and endpoints, but does not explicitly state that this is a read-only operation or disclose any usage limits or side effects.

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

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

The description is two sentences, front-loading the purpose and listing outputs. It is concise and well-structured, though the list of endpoints could be formatted more cleanly.

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 zero parameters and an output schema, the description covers the tool's purpose, outputs, and refresh policy. It misses explicit differentiation from siblings and limitations (e.g., only Base and Ethereum), but 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?

The input schema is empty, so the description cannot add parameter details. However, it compensates by listing the output fields and endpoints, providing context beyond the schema. Schema coverage is 100% (nonexistent parameters), so a baseline of 3 is exceeded.

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 on-chain intelligence for Base and Ethereum, listing specific data points like whale alerts, DEX volume, gas price, and TVL rankings. It is specific but could be more precise about the scope.

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

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

The description provides usage scenarios such as monitoring whale movements and DeFi health, but it does not include when not to use this tool or differentiate it from siblings like 'whale_alert' or 'aerocheck_pool'.

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 only mentions cost ($0.15) but fails to disclose important behavior such as side effects, idempotency, rate limits, or failure modes. 'Repurpose' is vague and does not clarify if the tool is read-only or mutative.

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 three sentences, front-loading the purpose and output formats. It includes a cost note efficiently. No unnecessary words, but the structure could be improved by separating input and output clearly.

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 there are no annotations and the output schema exists but is not described, the agent lacks knowledge of the return structure or behavioral traits. The description does not cover what happens after the call, error handling, or prerequisites, leaving 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 description coverage is 0% (no description for the 'url' parameter). The description adds little beyond the schema: it says 'any URL' but does not specify format, validation rules, or examples. The content of the description focuses on output, not the input 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?

The description clearly states the verb 'repurpose any URL' and specifies four distinct output formats (LinkedIn post, tweet thread, newsletter section, SEO meta summary). It immediately distinguishes the tool from the unrelated sibling tools (e.g., financial, weather, research).

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 guidance by indicating it is 'Best for turning research reports, blog posts, or news articles into ready-to-publish social content.' This gives context but does not explicitly state when not to use or mention alternatives.

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

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

No annotations provided, so the description carries the full burden. It describes the tool as verification (read-only) and lists returned data. It does not mention rate limits, errors, or required authentication, but the behavior is adequately described for a simple check tool.

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

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

Two sentences: first explains functionality and return data, second provides usage context. No wasted words, well-structured.

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

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

Given no annotations and an output schema (not detailed here), the description covers return fields and main use case. It could mention error handling or chain support, but is reasonably complete 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 description coverage is 0%, so the description must compensate. It mentions 'EVM address' (address param) and implies chain default ('eth'), but does not explicitly describe parameters or their constraints. Minimal additional value over 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: 'Smart contract verification for any EVM address' and lists specific return fields (verified, is_proxy, proxy_type, owner, deployment age). It distinguishes from sibling tools like token_due_diligence or rust_contract_audit by focusing on EVM addresses and proxy detection.

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 interacting with an unknown contract to detect hidden admin keys, upgradeable proxies, or unverified bytecode.' It doesn't list alternatives or when not to use, 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, so description carries full burden. It mentions the output includes TVL, audit status, etc., but doesn't disclose data sources, freshness, or any side effects. Adequate for a read-only tool but could be more 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?

Two sentences: first defines purpose and key metrics, second gives usage instructions. Efficient and front-loaded, 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 simple tool with one parameter and an output schema, the description covers purpose, usage, and what to expect. Complete enough for an 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?

Schema has one optional parameter 'protocol' with 0% description coverage. The description adds meaning: it's the protocol name to query, and an empty string returns top protocols overview. This compensates well for the lack of 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?

Description clearly states it's a DeFi protocol risk assessment tool, listing specific metrics (TVL, audit status, exploit history, smart contract risk). It distinguishes from sibling tools like 'token_due_diligence' and 'wallet_risk' by focusing on protocols.

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 how to use: pass a protocol name or leave empty for top protocols overview. While it doesn't list alternatives, the context of sibling tools implies this is specifically for DeFi protocol risk.

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 describes the return data (last 4 quarters of EPS, surprise, etc.) and parameter constraints, but does not explicitly state it is read-only or safe. The nature is implied but not explicit.

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 unnecessary words. Every sentence adds value: first sentence describes the data provided, second gives parameter details. Highly 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?

The tool has an output schema (not shown) and the description lists specific return fields, which is sufficient for use. No required parameters make usage simple. Could mention if there are limits (e.g., max tickers) but overall 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 0%, so the description must compensate. It explains both parameters: tickers as comma-separated string (adding format info) and days_soon as near-term window with default and maximum. This adds clear meaning beyond the schema.

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

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

The description clearly states the tool provides earnings dates, estimates, and beat/miss history with specific data points. It distinguishes itself from sibling tools like equity_analysis and insider_trading by focusing on earnings calendar data, though it does not explicitly differentiate.

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 parameter usage instructions (tickers as comma-separated, days_soon as near-term window) but does not provide when to use this tool versus alternatives or any when-not scenarios.

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

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

No annotations exist, and the description does not disclose any behavioral traits (e.g., data freshness, access requirements, side effects), leaving the agent without important contextual cues beyond the data listing.

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 single-sentence description is concise and front-loaded, but could be improved by grouping related items (e.g., prices vs. counts). No wasted words.

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

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

Given no parameters and the presence of an output schema, the description adequately enumerates the data points provided, making the tool's purpose and output fully clear.

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 zero parameters, the description need only clarify what data is returned. It does so concisely, covering the full scope of outputs. Baseline 4 applies per guidelines for 0-param tools.

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 'US energy market intelligence' and enumerates specific data points (WTI, Brent, Henry Hub, etc.), clearly distinguishing it from sibling tools focused on other sectors or data types.

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?

No guidance is provided on when to use this tool versus alternatives (e.g., industrial_metals, agricultural_commodities). The description lacks 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?

With no annotations, the description partially compensates by stating 'Cached 30 min,' which indicates staleness. However, it does not disclose other behavioral traits like authorization requirements, rate limits, or whether it is read-only. More detail would be beneficial.

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

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

The description is extremely concise: one sentence with key points separated by commas. It includes all essential information without unnecessary words.

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

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

Given the output schema exists, the description does not need to detail return values. However, concepts like 'health flags' and 'AI analysis' are not explained, leaving some ambiguity for a complex analysis 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 0%, and the description does not explain the 'ticker' parameter or its format. It only implies US tickers by saying 'US stocks and ETFs,' but lacks explicit guidance (e.g., 'AAPL' or 'SPY').

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 what the tool does ('buy/hold/sell signal, upside % to analyst target, P/E, EPS, health flags, AI analysis') and specifies the scope ('US stocks and ETFs'). It distinguishes from sibling 'tech_analysis' by focusing on fundamentals and analyst data.

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 provide when to use this tool versus alternatives. It only mentions 'US stocks and ETFs' and 'Cached 30 min' but lacks guidance on when to choose this over related tools like 'tech_analysis' or 'news_sentiment'.

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 for behavioral disclosure. It explicitly lists return elements (annualized rates, per-exchange breakdown, extreme alert, AI market bias) and the optional asset filter. It could mention data freshness or rate limits, but the provided info 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 three sentences long, front-loaded with the core function, and each sentence adds value without redundancy. It is efficient and readable.

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

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

Given the tool has one optional parameter and an output schema (not shown but implied), the description covers inputs, outputs, and signals sufficiently. It is complete for a data query 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 0%, but the description adds meaning to the single optional 'asset' parameter by stating it filters to a single coin. It does not specify allowed values but complements the schema enough to guide usage.

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 provides perpetual futures funding rates across Binance, Bybit, OKX for specific assets (BTC, ETH, SOL, etc.) and includes signal classification (LONG_HEAVY, etc.). It distinctly separates this tool from siblings like 'liquidations' or 'open_interest' which cover different financial data.

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

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

The description implies usage for retrieving funding rates with signal-first classification and optional asset filtering. However, it does not explicitly state when to use this tool over alternatives or provide exclusions, leaving room for improvement.

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 return types and that region can be left empty for global, but omits data sources, update frequency, or non-destructive 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?

Two sentences, no fluff. First sentence states purpose and outputs, second provides usage guidance. Front-loaded and efficient.

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

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

Given the presence of an output schema and low parameter count, the description adequately covers the tool's functionality and use case, with no major 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?

With 0% schema description coverage, the description adds crucial meaning: 'Pass a region name or leave empty for global overview', clarifying the single parameter 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 assesses geopolitical risk by region, specifies the outputs (risk_score, conflict signals, commodity impact), and distinguishes it from sibling tools focused on other domains.

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 (geopolitical events affecting trade/supply chain/commodity positions) but lacks when-not or alternative tool mentions, though siblings cover other areas.

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

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

No annotations are provided, so the description must disclose behavioral traits. It does not mention authentication needs, rate limits, or what happens if no results are found. It mentions cross-referencing stock tickers but does not explain the mechanism. Minimal disclosure.

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 the core function and result type. No superfluous content. Every sentence adds value.

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

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

With 3 optional parameters, no annotations, but an output schema (not shown) exists, the description explains the main outputs (agency breakdown, award amounts, AI narrative). It is mostly complete for a simple tool, though parameter details could be richer.

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 0%, so the description must add meaning. It mentions the $10M threshold (matching min_amount default) and 'agency breakdown' (implying agency filter). However, it does not explain the days_back parameter or the exact meaning of agency. Partial compensation.

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 federal contract awards from USASpending.gov for amounts $10M+, cross-referencing with stock tickers. This distinguishes it from many sibling tools, but not from 'gov_edge_opportunities', which likely focuses on opportunities.

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?

No explicit guidance on when to use this tool vs alternatives like 'gov_edge_opportunities'. The description implies it is for large contracts with stock ticker correlation but does not state when not to use it or provide exclusions.

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

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

With no annotations provided, the description carries the full burden. It discloses the data source (SAM.gov), the nature of results (active opportunities), and the inclusion of urgency flags. However, it does not mention rate limits, authentication needs, or data freshness, which are common for web scraping tools.

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 purpose and output, the second lists filters. Information is front-loaded and efficiently structured.

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

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

Given the presence of an output schema, the description need not explain return values. It adequately covers the tool's purpose, source, and filters. However, it could mention pagination, result limits, or the fact that only active opportunities are returned to be more 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 description coverage is 0%, so the description must compensate. It explains 'naics', 'keyword', and 'set_aside' (with examples of accepted values), but does not mention 'days_back' at all. The description partially adds meaning beyond the schema but misses one 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?

The description clearly states the tool searches active federal contract opportunities from SAM.gov, and lists the types of information returned (deadlines, urgency flags, agency, NAICS code, set-aside type, AI BD briefing). This distinguishes it from sibling tools like 'gov_edge' which likely has a broader scope.

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

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

The description provides context for when to use the tool (searching federal contract opportunities) but does not explicitly state when not to use it or compare to alternatives. While filters are listed, no guidance is given on choosing between this and other search tools.

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

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

No annotations are provided, but the description clearly states the tool is real-time, returns specified output fields, and costs $0.05 via x402. It discloses the paid nature and output structure, which is sufficient for a read-only data retrieval tool.

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

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

The description is a single, well-structured sentence that conveys all essential information upfront: what the tool does, which GPU models and providers, what it returns, and the cost. No redundant or unnecessary words.

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

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

The description explains the return fields (best_deals, market_signal, infrastructure brief) and mentions real-time data and cost. Although an output schema exists but is not shown, the description provides sufficient context for an agent to understand the tool's purpose and 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?

The tool has zero parameters, so the baseline is 4. No parameter details are needed, and the description does not add any parameter information beyond what the empty 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 explicitly lists specific GPU models (H100, H200, etc.) and providers (Vast.ai, RunPod, etc.), and states the tool returns best_deals, market_signal, and an infrastructure brief. It clearly differentiates from sibling tools which cover unrelated domains like agriculture, finance, and weather.

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 this tool is for GPU compute pricing but does not explicitly state when to use it versus alternatives. No exclusion criteria or alternative tool recommendations 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 must disclose behavioral traits. It mentions real-time data but lacks details on data freshness, rate limits, error handling, or what happens with invalid region. 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 two sentences plus a region code list. It is front-loaded with the purpose and use cases, with no fluff. 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 the tool has one optional parameter and an output schema, the description provides enough context: data types, use cases, and region codes. The existence of an output schema means return values are covered elsewhere, making the description 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 input schema has 0% description coverage, but the description thoroughly explains the region parameter: lists valid codes (CISO, ERCO, etc.) and specifies that leaving it empty queries all regions. This compensates fully for the schema's lack of documentation.

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 provides 'US electricity grid intelligence' with specific data types: real-time demand, generation mix percentages, and grid stress signals. It distinguishes itself from siblings like energy_markets by focusing on the electricity grid.

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 use cases: optimizing industrial operations, EV fleet charging, and compute workloads. It also explains region parameter usage with codes and default behavior. However, it does not mention when not to use or alternatives among siblings.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool writes code and opens pull requests (destructive actions), and mentions a cost. However, it lacks details on permissions, rate limits, or side effects beyond the core functionality.

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

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

The description is informative and reasonably compact, though the inclusion of the cost line could be seen as extraneous for tool selection. It is well-structured but not overly terse.

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 an output schema exists, the description adequately covers the tool's behavior, input parameters, and output (pr_url). It provides sufficient context for selecting and invoking the tool, though it could be more explicit about the 'context' parameter.

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 0%, so the description must compensate. It explains the 'task' and 'repo' parameters but does not explicitly describe the 'context' parameter, only hinting at its use for complex tasks. This leaves some ambiguity.

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 hires an autonomous coding agent that analyzes GitHub repos, writes code, runs tests, and opens pull requests. It distinguishes itself from sibling tools which are primarily financial or market-oriented.

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 specifies that the tool is best for well-scoped coding tasks like bug fixes and feature additions. It also mentions handling complex multi-step tasks. However, it does not explicitly exclude when not to use or name 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 bears the full burden. It discloses the data is real-time, lists costs ($0.05 via x402), and specifies coverage. However, it does not mention any side effects, rate limits, or access restrictions.

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 for purpose and coverage, one for cost. 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 no parameters and an output schema (not shown), the description fully covers what the tool does, what data it returns, and the cost. It is complete for a simple data retrieval 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?

With zero parameters, the baseline is 4. The description adds no parameter information but compensates by listing the exact metals covered, which adds 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 the tool provides real-time prices for 13 specified industrial metals, along with momentum signals and category analysis. It distinguishes from sibling tools like agricultural_commodities and energy_markets by explicitly listing the covered metals.

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 lacks explicit guidance on when to use this tool versus alternatives. It implies usage for obtaining real-time metal prices but does not mention when to choose it over similar data tools.

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

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

No annotations provided, so description carries full burden. It accurately describes the tool as returning a list of trades with specific fields, but does not mention any potential rate limits, authentication, or scope restrictions (e.g., only recent filings).

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

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

Two sentences: first states core function with output fields, second provides interpretative guidance and tool pairing. No wasted words, front-loaded with key information.

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

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

For a tool with one parameter and no annotations, the description covers purpose, output structure, and usage signals. It pairs well with sibling tools and explains trading relevance, though more details on data recency or limits would enhance 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?

The single parameter 'ticker' has 0% schema description coverage, but the description adds context by specifying it is a US stock ticker and detailing the output fields, compensating for the schema gap.

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

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

Description clearly states it returns SEC Form 4 insider trading activity for US stocks, listing specific fields and distinguishing from siblings by suggesting pairings with equity_analysis() and news_sentiment().

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?

Gives context on when to interpret results (bullish clusters, pre-earnings sales) and suggests complementary tools, but does not explicitly state when not to use this tool or list limitations.

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 lists what data is returned but does not disclose update frequency, rate limits, or whether the data is read-only. Additional behavioral context would improve 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?

Three sentences pack all necessary information without waste. The first sentence front-loads the purpose, and each subsequent sentence adds meaningful detail.

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 zero parameters and an output schema present, the description covers the tool's purpose and use cases well. However, it could mention data freshness or update frequency to be fully 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?

There are no parameters, so the description does not need to explain them. According to the guidelines, 0 parameters yields a baseline of 4, which 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 Latin American economic intelligence, listing specific currencies and indicators. It fully distinguishes from siblings by focusing on LatAm economies and crisis signals.

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?

Explicit use cases are given: 'Use for EM FX exposure, Argentina crisis monitoring, or commodity supply chain analysis.' This guides the agent on when to use it, though it lacks explicit 'when not to use' guidance.

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

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

No annotations exist, so the description must fully convey behavioral traits. It implies read-only intelligence retrieval but doesn't explicitly state read-only, rate limits, authentication needs, or any side effects. For a data tool, more disclosure is needed.

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, concise sentence that packs domain, source, scale, and key features. It wastes no words, but could benefit from additional structure to separate parameter hints or usage notes.

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 0% schema coverage, no annotations, and an unspecified output schema, the description fails to provide sufficient context. It does not explain what 'block status' means, how to interpret results, or how to use parameters effectively, leaving gaps 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 description coverage is 0%, yet the description adds no information about the three parameters (area, limit, status). It does not explain what values they accept, their effect, or the meaning of defaults like 'active'. The output schema exists but is not described.

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 providing Gulf of Mexico oil & gas lease intelligence from BOEM, mentioning scale (218k+ leases) and specific features (block status, upcoming BBG2 auction). However, it doesn't use an explicit verb like 'query' or 'retrieve', which marginally reduces clarity.

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 no guidance on when to use this tool vs. its siblings (e.g., energy_markets, supply_chain_intelligence). There is no mention of prerequisites, exclusions, or alternative tools.

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

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

No annotations are provided, so the description carries full burden. It discloses the data source (OKX), the assets covered, and the types of data (long vs short volume, biggest events, hottest zones). However, it lacks information on update frequency, rate limits, or any side effects.

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 5 sentences, front-loading the main purpose and then adding detail. Every sentence adds value, and it avoids redundancy with the schema.

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 and an output schema, the description is complete. It covers the assets, data types, signals, and how to combine with sibling tools for a fuller positioning picture.

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 parameters, so the schema coverage is 100%. The description does not need to explain parameters. It adds value by describing the data returned without relying on input documentation.

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 perpetual liquidation data for specific assets (BTC/ETH/SOL/AVAX/LINK/ARB) from OKX, and distinguishes itself from siblings by mentioning signals (LONG_CASCADE/SHORT_CASCADE/BALANCED/EXTREME) and pairing with funding_rates() and open_interest().

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 recommends pairing with funding_rates() and open_interest() for a complete picture, and states it is higher-signal than OI or funding rates, implying when to prefer this tool. However, 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 are provided, so the description fully carries the burden. It discloses all returned fields and adds interpretive context (e.g., 'negative = inverted = recession signal'). The behavior is a read-only snapshot with no side effects, and the description is complete.

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. It front-loads the purpose and list of indicators, then provides usage guidance. 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?

Given no parameters and an existing output schema (context signals confirm), the description is complete. It lists the key indicators and their interpretation, which suffices for this 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?

There are zero parameters, and the schema is an empty object. The description adds full meaning by listing the returned indicators and explaining their significance (e.g., yield curve spread and recession signal). This goes beyond the schema's trivial 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 returns a 'US macroeconomic regime snapshot' with specific indicators listed (fed_funds_rate, yield_curve_2s10s, etc.). It distinguishes itself from sibling tools like energy_markets or industrial_metals by focusing on broad macro indicators, and the pairing suggestions further clarify its scope.

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

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

The description explicitly states when to use: 'Use to assess whether macro conditions favor risk-on or risk-off positioning.' It does not mention when not to use or provide alternatives, but the pairing with equity_analysis and portfolio_risk gives useful 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?

No annotations provided, so description carries full burden. Discloses AI model (Claude Opus), types of vulnerabilities detected, output format (severity-graded report), and cost. Does not mention limitations like potential false positives or processing time, but overall transparent.

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

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

Three sentences, front-loaded with purpose, followed by scope, vulnerabilities, output, and cost. No unnecessary words, 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 annotations, the description covers purpose, input methods, detection capabilities, output format, and cost. Could mention error handling or rate limits, but overall complete for a specialized security tool. Output schema exists, so return details are adequately addressed.

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 0%, so description must add meaning. It explains the two input methods (source code or GitHub URL) and default contract name. While not detailing each parameter's format, it provides sufficient context for an agent to understand usage.

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 audits Move smart contracts, powered by CopperheadAI, covering Aptos and Sui. Lists specific vulnerabilities detected and output format. Distinguishes from sibling tools like rust_contract_audit and smart_contract_audit by focusing on Move language and VM-specific patterns.

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 instructs to provide raw Move source code or GitHub URL, and mentions cost. Does not explicitly state when to avoid using this tool or compare to alternatives, but the specialization implies context for Move contracts.

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

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

With no annotations provided, the description carries full behavioral disclosure burden. It mentions 'Cached 5 min', indicating data freshness, but does not address read-only nature, permissions, or rate limits. The caching disclosure is useful but incomplete for comprehensive 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 extremely concise, consisting of two short sentences with no redundancy. Every word adds value—first sentence defines purpose and outputs, second adds caching behavior. No wasted content.

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 presence of an output schema, the description adequately covers the tool's purpose (multi-timeframe confluence), outputs (signal, score, breakdown, narrative), and caching. It lacks details like what 'AI narrative' entails, but the output schema likely fills gaps. Overall sufficient 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?

Schema coverage is 0%, so the description must compensate. The single 'symbol' parameter is implied from context (e.g., scanning across timeframes for a symbol), but no explicit format guidance (e.g., 'AAPL' vs 'BTC/USD') is given. The description adds minimal meaning beyond the parameter name.

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 multi-timeframe technical analysis confluence across 15m/1h/4h/1d, listing specific outputs like overall_signal, confluence_score, etc. It distinguishes from simple single-timeframe tools but does not explicitly differentiate from siblings like 'tech_analysis'.

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 no guidance on when to use this tool versus alternatives (e.g., 'tech_analysis'), nor does it mention prerequisites, limitations, or complementary tools. It only states what it does, requiring the agent to infer usage 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?

No annotations provided, so description carries full burden. It describes return fields and auto-routing for crypto, but lacks details on rate limits, authentication, or side effects. Adequate for a simple query 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?

Description is concise with two key sentences and a pairing suggestion. Every sentence adds value, no fluff, and purpose is 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?

Given one required parameter, no annotations, and existing output schema, the description covers purpose, usage, and related tools. Lacks parameter format details, but overall reasonably complete.

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

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

Schema description coverage is 0% and the description does not elaborate on parameter format (e.g., ticker vs company name, case sensitivity). The single parameter 'query' lacks sufficient guidance for proper use.

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 provides real-time news sentiment for stock tickers or crypto assets, with specific output fields. It distinguishes from siblings by mentioning it pairs with equity_analysis, tech_analysis, and insider_trading.

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 advises using before a trade to detect sentiment regime or monitor news flow, and mentions crypto auto-routing. It does not explicitly state when not to use, but provides clear context and related tools.

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

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

No annotations provided, so description carries full burden. Clearly discloses signals (ACCUMULATING/DELEVERAGING/MIXED) and return components. Does not mention safety or side effects, but as a read-only data tool, the description is adequate. Could explicitly state it's read-only.

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

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

Three sentences, front-loaded with key scope and output details. Every sentence adds value: purpose, signal explanation, return items, pairing suggestion. 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 output schema exists, description need not explain return format. Covers all critical aspects: assets, exchanges, signals, output components, and complementary tool. Zero parameters simplify 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?

Input schema has zero parameters (100% coverage by default). Baseline score 4 for no params. Description does not add parameter info, but none is needed.

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

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

Specific verb ('returns') and resource ('perpetual futures open interest across OKX, Hyperliquid, dYdX for BTC/ETH/SOL/AVAX/LINK/ARB'). Explicitly describes output: USD totals, per-exchange breakdown, 5-min OI delta, dominant exchange. Differentiates from sibling tools by mentioning pairing with funding_rates().

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?

States context: perpetual futures open interest. Provides pairing advice with funding_rates() for a complete positioning picture. No explicit when-not-to-use or alternatives, but clear intent distinguishes it from 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 carries the full burden. It discloses latency (crypto under 1s, stocks cached 5 min) and return fields, but does not mention authorization requirements, destructive potential (likely read-only), or rate limits. Additional context like limits or permissions would strengthen 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 extremely concise—two sentences that front-load the core purpose and immediately deliver key distinctions (stocks vs crypto, latency) without any extraneous information. Every word 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?

Given the single required parameter and the existence of an output schema (which presumably documents return values), the description is sufficient. It covers the tool's scope, supported assets, data provided, and latency. Minor gaps like data sources for stocks or behavior for invalid tickers are not critical.

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 schema coverage at 0%, the description adds meaning by specifying that the ticker can be a stock or crypto symbol (with explicit crypto examples: BTC/ETH/SOL/AVAX via Deribit). This compensates for the schema's lack of description and provides useful 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 the tool provides options flow for stocks and specific crypto assets (BTC/ETH/SOL/AVAX via Deribit) and lists the returned data (signal, conviction trade, put/call ratio, unusual activity). It does not explicitly differentiate from sibling tools like equity_analysis or news_sentiment, but the purpose is unambiguous.

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

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

The description implies usage for obtaining options flow data and contrasts latency between crypto and stocks, but does not provide explicit when-to-use guidance or alternatives. The context is implied rather than stated.

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 disclose behavior. It states the conversion action and return values but does not discuss limitations (e.g., password-protected PDFs, URL accessibility, size limits), which would be helpful.

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 redundancy, front-loaded with core function and output, then use cases. Every word 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?

Given a simple parameter set and presence of output schema, the description covers main functionality and use cases but omits edge cases (e.g., error handling, unsupported PDF types). Still satisfactory.

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 0%. Description indirectly hints at the 'summarize' parameter (mentions AI summary) but does not explain 'url' or the effect of the boolean parameter, leaving gaps for the agent.

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 converts PDF documents via URL to clean Markdown, lists return values (markdown text, page count, word count, table count, metadata, AI summary), and is distinct from all 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 provides explicit use cases ('whitepapers, reports, contracts, or research papers') but lacks when-not-to-use or alternative tools, though no direct siblings exist.

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

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

Discloses the analysis scope (concentration, volatility, correlation) but does not state whether it is read-only, requires authentication, or has any limitations. No annotations provided, so description carries the burden.

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, zero waste. 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?

With an output schema present, the description covers the essential input format and analysis types. No missing critical information for a single-parameter tool.

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

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

Adds meaningful format guidance ('comma-separated string' with example) beyond the schema which only specifies type 'string'. Schema coverage 0%, so description compensates 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?

Clear verb+resource: 'Portfolio risk analysis — concentration, volatility, correlation.' Distinguishes from siblings like equity_analysis or defi_risk by focusing on risk metrics for a portfolio of tickers.

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?

Only provides input format ('Pass tickers as comma-separated string') but no guidance on when to use vs alternatives or when not to use. No exclusions or context about 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?

No annotations are provided, so the description must fully convey behavior. It lists the data provided but does not mention update frequency, rate limits, or any side effects. For a read-only tool with no parameters, the transparency is adequate but could include more context.

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

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

The description is a single sentence that efficiently conveys the tool's content. It is front-loaded with 'US real estate market' and lists key indicators without excess verbiage. Could be slightly more structured but is well within acceptable brevity.

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 zero parameters and the presence of an output schema (not shown), the description sufficiently explains what the tool returns. It covers all major data points. Lacks mention of update frequency or data source, but for such a focused tool, it is nearly complete.

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

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

The tool has zero parameters, so schema coverage is 100%. The description adds all meaning by specifying exactly which data points are returned, going beyond the empty input schema to fully define the tool'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?

The description clearly specifies the tool's purpose: providing US real estate market data including mortgage rates (30yr/15yr/ARM), housing starts, months supply, Case-Shiller HPI, and affordability index. It distinguishes itself from siblings like macro_indicators by focusing specifically on real estate metrics.

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?

No guidance is given on when to use this tool versus alternatives like macro_indicators or geo_pulse. The description implies use for US real estate data but lacks explicit recommendations or exclusions.

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 it auto-detects the framework, runs targeted checks, returns a severity-graded report with root cause analysis and fixes, and mentions cost. However, it does not explicitly state that the tool is read-only or non-destructive, though implied by 'audit'.

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 three sentences with clear front-loading of purpose, followed by detailed checks and input instructions. 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 the tool's complexity (multi-framework audit) and lack of output schema in input, the description covers framework detection, specific checks, report format, input methods, and cost. It is mostly complete, though it could mention any limits on code size or number of files.

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 3 parameters with 0% coverage in schema descriptions. The description partially compensates by explaining 'source' and 'github_url' input methods, but does not explain the 'contract_name' parameter (default 'Contract'). The user must infer its purpose from the name.

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 performs a security audit of Rust smart contracts, auto-detects the framework (CosmWasm, Anchor/Solana, Stellar/Soroban, NEAR), and lists specific checks (unsafe arithmetic, missing account validation, etc.). This clearly distinguishes it from sibling tools like contract_check or smart_contract_audit.

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 tells the user to provide raw Rust source code or a GitHub URL, and mentions the cost. It implicitly guides usage by focusing on Rust contracts, but does not explicitly state when not to use (e.g., non-Rust contracts) or contrast with siblings like move_contract_audit. Still, 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?

Describes key behaviors: uses RattlerAI and Slither, cross-validates findings, returns severity report with root cause analysis and fix recommendations. Also mentions cost. No annotations to contradict. Minor gap: no detail on execution time or authentication.

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 5-sentence description front-loads the main purpose. Every sentence adds unique value: vulnerability list, cross-validation, output format, use case, input format, cost. 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?

Covers main aspects: detection scope, validation, output format, input options, cost. With an output schema present, return values are adequately described. Minor omissions: no explanation of contract_name parameter.

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?

Description explains that source or github_url should be provided, but contract_name is not described. With 0% schema coverage, description partially compensates but misses the purpose of the third 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?

Clearly states it performs a Solidity smart contract security audit, lists many vulnerability classes, and distinguishes itself from sibling tools like rust_contract_audit and move_contract_audit by focusing on Solidity and using RattlerAI.

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?

Ideal use case is stated: pre-deploy sanity check or audit triage. Input format specified: Solidity source code or GitHub URL. Does not explicitly mention when not to use or compare to similar tools like contract_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?

No annotations are provided, so the description carries the full burden. It lists the outputs but does not mention any side effects, rate limits, or data freshness. Since it's a monitoring tool, destructive behavior is unlikely, but the description could be more explicit about safety.

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

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

Two sentences with no wasted words. The description is front-loaded with purpose and immediately gives actionable usage instructions.

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 optional parameter and an output schema (presumably detailing metrics), the description covers the main functionality and usage. No gaps remain for an agent to understand how 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?

The schema has 0% coverage, but the description adds specific valid values (USDC/USDT/DAI/FRAX) and explains the effect of leaving it empty. This meaningfully supplements 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 monitors stablecoin stability and lists specific metrics (peg deviation, backing ratio, etc.). It differentiates from sibling tools by focusing exclusively on stablecoins, which are distinct from other asset classes.

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 when to pass a symbol vs leave empty for a full report, providing clear usage context. No explicit exclusions or alternatives are given, but the guidance is sufficient for a simple tool.

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

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

No annotations are provided, so the description carries full burden. It discloses that data is live, lists sources (Coinbase, Kraken, Binance, DeFiLlama), mentions a cost of $0.05, and describes output structure including risk level. It clearly indicates a read-only data retrieval operation with no destructive actions.

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

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

The description is a single dense paragraph that front-loads the main purpose and then details the specific data points. Every sentence adds value, with no wasted words, appropriate for the tool's 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 the tool has one optional parameter, no required params, and the output schema exists, the description covers the key output fields (APY, exchange rates, liquid staking, best_strategy) and explains when to use it. It is complete enough for an agent to understand 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?

Input schema has one optional parameter 'symbol' with default '', and schema description coverage is 0%. The description adds meaning by explaining that the symbol filters for a specific asset (ETH, SOL, etc.) and leaving it blank returns the full report. This compensates for the lack of schema documentation.

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 live staking yield comparison across 7 specific assets, lists the types of returns (protocol APY, exchange rates, liquid staking, liquid restaking), and mentions a best_strategy field. This is specific and distinguishes it from sibling tools which are mostly other financial data 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 'Use when an agent needs to know where to stake an asset for maximum yield.' It also explains how to filter by symbol or leave blank for full report. This provides clear when-to-use and usage instructions.

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 transparency burden. It mentions the endpoint and cost, and implies read-only behavior, but lacks details on idempotency, rate limits, or caching. The behavioral disclosure is adequate but not comprehensive.

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

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

The description is concise (three sentences) and front-loaded with the core purpose. Each sentence adds value: defining the monitor, listing outputs, and providing cost/endpoint details. No wasted words.

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

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

The tool has an output schema, so the description does not need to detail return values. It already enumerates the key outputs and gives interpretive context. No apparent gaps given the no-parameter simplicity.

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

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

The tool has zero parameters, so the description is not required to add parameter information. Given the baseline of 4 for zero parameters, this score 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 identifies the tool as a global supply chain stress monitor and lists specific outputs (stress_score, shipping rates, indices, etc.), making its purpose distinct from siblings like energy_markets or agricultural_commodities.

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

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

The description implies usage for assessing supply chain stress but does not explicitly state when to use or when not to use, nor does it mention any alternatives. It provides context by explaining what high stress_score signifies.

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 results are cached for 5 minutes and lists available timeframes. It does not mention authorization or rate limits, but the tool is read-only and simple.

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 no filler. Front-loads the main purpose and key details (indicators count, AI, timeframes, caching). Every word 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?

Given the presence of an output schema, return values need not be explained. However, the description does not specify parameter formats (e.g., symbol casing, timeframe string exactness). It is adequate but not 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 0%, so description must compensate. It explains the symbol is required and timeframe defaults to '1d', listing allowed values (15m,1h,4h,1d). 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?

The description clearly states the tool provides '18 technical indicators + AI signal for any ticker' with specific timeframes. It distinguishes itself from siblings like equity_analysis by focusing on technical analysis.

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

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

The description implies usage for technical analysis but does not explicitly state when to use this tool over alternatives like multi_timeframe_scan or equity_analysis. No when-not-to-use guidance is 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 must fully convey behavioral traits. It indicates a read-only analysis but does not disclose potential side effects, rate limits, data source dependencies, or how results should be interpreted. The description is too basic to ensure safe and effective 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 two sentences, front-loading the main purpose and then listing supported chains. Every part is relevant, and there is no verbosity. It is efficiently structured for quick reading.

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 an output schema, so return values are presumably documented there. The description covers the main aspects of the tool (what checks are performed, supported chains) but omits details about risk score interpretation or what each check entails. It is adequate for a basic understanding but lacks depth.

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 0%, meaning no parameter descriptions exist in the schema. The description adds some value by listing supported chains for the chain parameter, but it does not explain the contract_address parameter or any constraints. The agent requires more detail to correctly set parameters.

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

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

The description clearly states the tool performs 'Full ERC-20 token due diligence' and enumerates checks like risk score, honeypot check, liquidity, holder concentration, and ownership status. It also lists supported chains. However, it does not differentiate this tool from similar sibling tools like contract_check or defi_risk.

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 no guidance on when to use this tool versus alternatives. It lacks context such as prerequisites, typical use cases, or when not to use it. This omission leaves the agent without decision support for tool 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 are provided, so the description carries full burden. It discloses that the tool scans and filters for honeypots and returns risk score, liquidity, etc. This adequately conveys the non-destructive, read-only nature of the tool. However, it could mention rate limits or call frequency 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 two sentences, front-loaded with the action, and contains no extraneous 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?

Given no parameters and an existing output schema, the description covers the purpose and output sufficiently. However, it could explicitly note that no input parameters are required for clarity.

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 tool has 0 parameters with 100% schema coverage, and the baseline for 0 params is 4. The description adds no parameter info, which is acceptable since there are none, but it explains what the tool does without input parameters.

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

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

The description uses the specific verb 'scan' and identifies the resource as 'newly launched tokens'. It distinguishes from siblings by focusing on filtering for legitimate launches vs honeypots and specifying the output (risk score, liquidity, deployer history, launch metadata). This provides clear differentiation from other 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 implies usage for initial scanning of new tokens but does not explicitly state when to use this tool vs alternatives like contract_check or token_due_diligence. No guidance on when not to use it or prerequisites is 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?

The description enumerates the return fields (realized/unrealized gains, portfolio value, win rate, holdings, verdict), providing a good snapshot of the output. However, it does not disclose any behavioral traits such as data freshness, accuracy, rate limits, or what happens for inactive wallets. Since no annotations are provided, the description should cover more behavioral context.

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

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

The description is a single sentence that efficiently conveys the tool's purpose and outputs without waste. It is front-loaded with the core function. A slight improvement could be breaking into bullet points, but it remains highly 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 (PnL analysis) and the existence of an output schema, the description covers the return values adequately. However, it omits any explanation of the required wallet parameter or the optional days parameter, leaving a gap in completeness. Overall, it is insufficient for full autonomous use.

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

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

The input schema has two parameters (wallet, days) with no descriptions (0% coverage). The tool description does not mention or explain either parameter, so it adds no meaning beyond the raw schema. The agent must infer that 'wallet' is an on-chain address and 'days' is a time range.

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 an on-chain wallet PnL analyzer for Base, listing specific outputs (gains, portfolio value, win rate, holdings, verdict). This precisely defines the tool's function and distinguishes it from sibling tools like wallet_risk or token_due_diligence.

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?

No guidance is given on when to use this tool versus alternatives such as wallet_risk, token_due_diligence, or other analysis tools. There is no mention of prerequisites, limitations, or context for use.

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

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

No annotations provided, so description carries full burden. Describes outputs but does not disclose rate limits, permissions, or side effects. For a read-only query, it is moderately 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?

Two sentences with no redundancy. Front-loaded with core purpose.

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

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

Output schema exists and description lists many fields, but lack of parameter details and no annotations leave minor gaps. Adequate for a simple risk assessment 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 0%, and description does not explain input parameters (e.g., 'chain' defaults to 'eth', address format). Adds meaning only for outputs, not inputs.

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 returns a wallet risk score for Ethereum addresses, listing specific output fields. Distinguishes from siblings like defi_risk and token_due_diligence by focusing on wallet-level risk.

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 transacting with unknown counterparty or for compliance screening. No explicit when-not or alternatives, but the context is well-defined.

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

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

With no annotations, the description bears full burden. It discloses auto-fetching of Base on-chain holdings, valuation, and flagging behavior. It lacks details on error handling or chain-specific limitations but is generally 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?

Three sentences with no redundant information. The first sentence states the tool's purpose, the second details wallet input behavior, and the third covers additional inputs and outputs. 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 description covers inputs, process, and outputs adequately for a tool with an output schema. It omits prerequisites and error scenarios but is otherwise complete given the schema richness.

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 0%, so the description must explain parameters. It does so by mapping 'wallet' to on-chain data, 'tickers' to stocks, and 'contracts' to tokens, though it could specify expected formats (e.g., wallet address, ticker symbols).

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 'Cross-asset portfolio risk analyzer' and specifies inputs (wallet, tickers, contracts) and outputs (risk score, narrative, flags), distinguishing it from more narrow sibling tools like wallet_risk or portfolio_risk.

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

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

The description states when to use the tool by listing accepted inputs and the unified risk output, but does not explicitly contrast with siblings or provide when-not-to-use guidance. Still, the usage context is clear.

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

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

With no annotations, the description fully discloses behavioral details: the model composition, probabilistic outputs, blending formula (60% empirical / 40% Gumbel), method_divergence logic forcing PASS when disagreement exceeds 0.15, and cost of $0.02. This provides complete transparency about the tool's 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 dense but well-structured, opening with the core capability and then detailing outputs, behavior, and cost. Every sentence adds value, though it could be slightly more organized (e.g., grouping parameter explanations together).

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 params, output schema exists), the description covers the essential outputs and parameter behaviors. The presence of an output schema reduces the need for return value detail, and the description compensates well for the lack of annotations.

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?

Despite 0% schema description coverage, the description explains the 'direction' parameter as 'greater' or 'less', lists supported cities, and clarifies that providing a threshold yields additional outputs. It does not detail the 'date' parameter format, but overall adds significant meaning beyond the bare schema.

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

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

The description clearly states it provides weather probability using a 7-model consensus and 80 ensemble members. It specifies the output includes probability, prob_exceeds, method_divergence, signal, and outlier. It lists supported cities and parameters, making the tool's purpose highly specific and distinct from any sibling tools (none are weather-related).

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives. It mentions alignment with NWS ASOS stations used by Kalshi/Polymarket, implying a use case for prediction markets, but lacks direct instructions on appropriate contexts 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?

Since no annotations are provided, the description must disclose behavioral traits. It mentions 'real-time' and that it returns a list, but does not clarify idempotency, read-only nature, potential rate limits, or error handling. The inferred read-only behavior is not explicitly stated.

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 no wasted words. It leads with the core purpose, then details the output, then provides usage guidance. 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?

With an output schema present, the description does not need to explain return values. It covers input parameter, use case, and output summary thoroughly 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 single parameter 'min_usd' is explained: 'Pass min_usd to set threshold (default $1M).' Given 0% schema description coverage, the description effectively adds meaning beyond the schema by specifying the default and 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 it provides 'real-time whale transfer alerts on Base and Ethereum' and lists the returned fields (sender, receiver, token, amount, USD value). It is specific and distinguishes this tool from any obvious sibling by focusing on large transfers with threshold.

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 to 'Use to detect smart money movements or monitor an ecosystem for unusual capital flows.' While it doesn't mention when not to use or alternatives, the context makes the use case clear.

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