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

No annotations are provided, so the description carries the full behavioral burden. It does not state whether this is a live read, which DEXes are covered, what the comparison output looks like (best price, spread, list of quotes), or whether any permissions or rate limits apply. 'Compare' implies a non-destructive read, but the agent must guess at the rest.

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?

A single sentence with zero filler, and the scoping constraint ('on the same network') is front-loaded alongside the core action. 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?

With no annotations and no output schema, the description should explain what the comparison returns (e.g., per-DEX quotes, best venue, spread) and any coverage limits. It leaves the return value and DEX coverage entirely unspecified, which is a meaningful gap for a comparison tool whose output shape is unknown.

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

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

Schema coverage is 100%, with both 'symbol' and 'network' documented in the schema, so the baseline is 3. The description adds the useful semantic that network must match across DEXes ('on the same network'), but it does not add format guidance beyond the schema's example networks.

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

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

States a specific verb ('Compare') and resource ('token prices across different DEXes on the same network'), which tells an agent this is a cross-venue price comparison rather than a single-price lookup. It does not explicitly differentiate itself from siblings like get_crypto_price or get_dex_info, but the scope is clear enough to distinguish by inference.

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 phrase 'on the same network' implies the tool's operating context and the constraint that both DEXes must share a network, but there is no explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. Usage is inferable but not directed.

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 supplied, so the description carries the full burden and discloses almost nothing beyond the pattern names. It does not say whether detection runs over historical OHLCV, whether results include confidence or price targets, how many patterns are returned, or how much data the timeframe requires.

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?

A single compact sentence that leads with the verb and backs it with concrete pattern examples. Nothing is wasted, though the sentence does no more than the minimum.

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?

There is no output schema and the description explains nothing about the return value, which for a pattern detector is the critical unknown (detected pattern list, direction, confidence, range). With no annotations either, an agent cannot predict the response shape.

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

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

Schema coverage is 100% and both parameters (symbol, timeframe with accepted values and default) are already documented in the schema. The description adds no additional meaning such as how timeframe affects pattern reliability, so the baseline 3 applies.

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

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

States a specific verb (detect) and resource (chart patterns) and enumerates examples (head & shoulders, triangles, double tops/bottoms), so an agent knows exactly what it produces. It does not distinguish itself from analytical siblings such as get_technical_indicators, get_support_resistance, or multi_timeframe_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?

There is no statement of when to use this rather than the many overlapping technical-analysis siblings, nor any prerequisites or exclusions. The only hint of usage is the implicit 'this is technical analysis' framing.

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. 'Get list of' implies a read-only, side-effect-free enumeration, which is good, but it says nothing about whether the list is static or configured, or how entries are identified (names vs. IDs) for use in sibling tools. For a simple zero-param listing tool this is a moderate rather than severe gap.

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?

A single front-loaded sentence with no filler or redundancy, appropriately sized for a trivial listing tool. It is efficient but offers no additional qualifying 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 no output schema and no annotations, the description is the only source of truth, and it leaves the return shape (what fields each network entry has, what identifier other tools expect) unspecified. Adequate for an agent to decide to call it, but incomplete for using the result correctly downstream.

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 takes zero parameters and the input schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless tool.

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

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

The description states a specific verb and resource ('Get list of all supported blockchain networks'), which is unambiguous about what the tool returns. It implicitly distinguishes itself from siblings like get_network_pools by making clear this is the network inventory, though it never names an alternative explicitly.

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?

Usage is only implied: an agent can infer this is a discovery step to find valid network identifiers before calling get_network_pools or get_token_liquidity. The description never says when to call it or that its output feeds other tools, so the routing logic is left to inference.

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 does not disclose the data source/exchange, quote currency, freshness/latency, rate limits, or authentication requirements, which matter for a price 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?

One efficient, front-loaded sentence with no wasted words. It is appropriately sized for a simple read tool, though it could include one clause on data source or currency.

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

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

For a simple one-parameter read tool with no output schema, this is minimally adequate: it tells the agent what is returned in broad terms. It is incomplete on data provenance, quote currency, and whether 'market data' includes volume/market cap, which the agent would need to set expectations.

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

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

Schema description coverage is 100% and the single parameter is documented with examples (BTC, ETH, ADA). The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

States a specific verb ('Get') and resource ('current price and market data for a cryptocurrency'), so the agent knows exactly what it returns. However, it does not distinguish itself from siblings such as get_technical_indicators, get_trading_signals, or compare_dex_prices, which also return crypto market 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?

No guidance on when to use this versus the many sibling analysis tools, no exclusions, and no prerequisites. The agent must infer usage from the name alone.

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, and it discloses nothing beyond the one-line purpose — no indication of what the returned 'information' contains, whether results are cached/static, or how large the listing may be. For a read-only lookup the risk is low, but the disclosure gap is real.

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?

One short sentence, front-loaded with the verb and resource, with zero filler. Nothing could be trimmed without losing the scope qualifier.

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 no output schema and no annotations, the description should hint at what the response looks like (e.g., DEX names, ids, chains) so an agent can plan downstream calls. It is adequate for a simple lookup but leaves the return shape entirely unspecified.

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

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

Schema description coverage is 100% and the single 'network' parameter is already documented with examples (ethereum, solana). The description's phrase 'on a network' merely restates the schema, adding no format or validation detail beyond it, so baseline 3 applies.

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

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

States a specific verb ('Get information') and resource ('DEXes') scoped to a network, which reads clearly and is distinct from siblings like get_network_pools or get_pool_analytics. The weak point is that 'information' is unspecific about what fields are returned, but the resource 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 per-network framing implies when it is useful (discovering which DEXes exist on a chain), but there is no explicit when-to-use/when-not guidance and no reference to alternatives such as get_network_pools or compare_dex_prices.

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

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

With no annotations, the description carries the full disclosure burden, yet it says nothing about whether this is a read-only aggregation, how expensive/slow a multi-signal computation is, whether results are cached, or how errors on partial data are handled. Only the obvious 'get implies read' is conveyed.

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

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

A single front-loaded sentence with zero filler. It is efficient, though the brevity borders on under-specification for an aggregate analysis tool.

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

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

For a no-annotation, no-output-schema tool that bundles many analyses, the description omits what the response actually contains (structure, per-indicator breakdown) and any behavioral caveats. It is minimally adequate but leaves the agent guessing about return shape and cost.

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

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

Schema description coverage is 100%, with symbol, timeframe, and risk_level all documented in the schema, so the description need not repeat them. It adds no meaning beyond the schema (e.g., effect of risk_level on signals), so baseline 3 applies.

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

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

The description gives a specific verb (get) and resource (comprehensive technical analysis) plus enumerates the scope: all indicators, patterns, and signals. It is clear what the tool returns, but it never names the sibling tools it aggregates (get_technical_indicators, detect_chart_patterns, get_trading_signals), so an agent must infer the aggregate-vs-single distinction itself.

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?

"Comprehensive ... including all indicators, patterns, and signals" implies the tool is the one-stop alternative to the granular siblings, but the description never states when to use this versus them, nor any cost/latency tradeoff for the broader call. Usage is left 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 are provided, so the description carries the full behavioral burden. The verb 'Get' signals a read operation, but there is no explicit read-only confirmation, no mention of rate limits, pagination, or return 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 a single front-loaded sentence with no wasted words. Its brevity is appropriate for a simple read tool, even though other dimensions suffer from under-specification.

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 low-complexity and the schema fully documents its parameters, but there is no output schema and no annotations. The description does not explain return values, default result size, or ordering beyond what the schema states.

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

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

Schema description coverage is 100%, so the schema already documents network, limit, and sort_by. The description adds 'top' and 'specific network' but no syntax, defaults, or filtering semantics beyond what the schema provides.

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

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

The description states a specific verb and resource: 'Get top liquidity pools on a specific network.' It is clear and scoped, though it does not explicitly distinguish itself from nearby siblings such as get_pool_analytics or get_token_liquidity.

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 listing top pools on a network, but it gives no explicit when-to-use guidance, no exclusions, and no named alternatives. An agent must infer its role from the name alone.

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 supplied, so the description carries the full behavioral burden and discloses almost nothing: not whether results are cached/realtime, not the time window covered, not whether the pool must exist on the given network. Only the implicit read-only nature of 'get' is conveyed.

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

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

A single front-loaded sentence with no filler. It is efficient, though the efficiency comes partly from saying very little.

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 no output schema and no annotations, the description would need to explain what 'analytics' comprises (TVL, volume, fees, APR, time range). It does not, leaving the agent unable to predict the response or judge relevance.

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

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

Schema description coverage is 100%, with both required parameters documented, so the schema already does the heavy lifting. The description adds no format hints (e.g., address case sensitivity, supported network naming), so the baseline 3 applies.

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

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

States a verb and resource ('get detailed analytics for a specific liquidity pool'), which is more than a tautology, but 'analytics' is an undefined umbrella term. Siblings like get_pool_ohlcv and get_token_liquidity carve out similar territory, and the description gives no signal about how this differs.

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?

There is no indication of when to choose this over get_pool_ohlcv, get_token_liquidity, or get_full_analysis, and no prerequisites or exclusions are stated. The agent must infer usage entirely from the name.

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

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

No annotations are provided, so the description must carry the full behavioral burden. 'Get' implies a read-only operation, but the description does not state permissions, rate limits, error behavior, or data source, leaving significant gaps for a 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, front-loaded sentence with no wasted words. It is efficient, though its terseness contributes to gaps in other dimensions rather than being a conciseness issue.

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

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

The tool has no output schema and no annotations, so the description should ideally explain return format or data limitations. The schema fully documents parameters, making the definition minimally adequate, but it omits what the response looks like and any constraints on data availability.

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

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

Schema description coverage is 100%, so every parameter is already documented in the input schema. The description adds no additional meaning beyond what the schema provides, which is the baseline expectation when schema coverage is high.

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

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

The description uses a specific verb ('Get') and resource ('historical OHLCV (candlestick) data') scoped to 'a liquidity pool', making the operation clear. However, it does not differentiate this tool from siblings like get_pool_analytics or get_technical_indicators, so it falls short of full sibling differentiation.

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?

There is no indication of when to use this tool versus alternatives, no prerequisites, and no exclusions. The agent receives no guidance on selecting this over other pool-related analytics tools.

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

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

No annotations are provided, so the description carries the full burden of disclosure and does not meet it. It does not say how levels are computed, whether it is a read-only analysis, how many levels are returned, or what happens with an unsupported timeframe. Only the word 'find' weakly implies a read operation.

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

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

A single short sentence with no wasted words, and the core capability is front-loaded. Brevity is the issue only in that too little is said, not in verbosity.

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 no output schema, the description should explain what the response contains, such as whether levels are price points with strength scores, and how timeframe affects results. For example, it should clarify whether daily is the default, while the schema covers the enum values. As written, it leaves the agent unable to predict the output.

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

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

Schema description coverage is 100%: both symbol and timeframe are documented, including the timeframe enum values and the default of daily. The description adds no further meaning about parameters, so the schema baseline of 3 applies.

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

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

The description names a specific verb and resource: finding support and resistance levels. That is clear enough that an agent knows the general capability. However, it offers no differentiation from nearby siblings such as get_technical_indicators, detect_chart_patterns, or multi_timeframe_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?

There is no guidance on when to use this tool versus alternatives, and no mention of prerequisites such as the need for historical price data. The agent must infer from the name alone whether to call this tool or get_technical_indicators.

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 implies a read-only computation but never states that nothing is mutated, that it requires historical candle data, whether timeframes must be pre-supported, or what the response contains — significant gaps for a bare 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?

A single efficient sentence with the actionable content (which indicators) up front and no filler. It is sparse rather than padded, though it could carry one more clause about usage or output without bloat.

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 no output schema and no annotations, the description should explain the shape of the returned indicator series and any constraints on timeframe/symbol coverage; it explains neither. For a 3-parameter analytical tool in a crowded sibling set, this leaves the agent guessing.

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

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

Schema coverage is 100%, so the required symbol, timeframe options, and optional indicator array are already fully documented in the schema. The description's indicator list adds marginal mapping to the 'indicators' parameter but no syntax, accepted values, or defaults beyond what the schema states.

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

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

States a specific verb+resource ('Calculate technical indicators') and enumerates the actual indicator families computed, so an agent knows exactly what comes back. It does not differentiate from siblings like get_trading_signals, detect_chart_patterns, or multi_timeframe_analysis, which overlap heavily in this namespace.

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 statement of when to use this versus get_trading_signals, get_support_resistance, or multi_timeframe_analysis, and no prerequisites (e.g. whether OHLCV data must exist for the symbol/timeframe). Usage is inferable only from the name and indicator list.

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

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

No annotations exist, so the description must carry the full behavioral burden and it does not. It doesn't say what 'liquidity information' includes (TVL, depth, slippage, price impact), whether results are aggregated across DEXes, whether a missing network searches all chains, or whether the call is read-only and rate-limited.

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?

One short sentence, front-loaded with the action and resource. Nothing wasted, though there is also very little content to structure.

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

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

For a tool with no annotations and no output schema, the description should specify what liquidity metrics are returned and how multi-DEX aggregation behaves. As written, an agent knows only the topic, not the result shape or scope semantics.

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

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

Schema description coverage is 100%, so both parameters (symbol, optional network) are already documented with examples. The description adds only the 'across all DEXes' aggregation framing, which hints that network is an optional narrowing filter, but adds no real syntax or semantics 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?

States a specific verb ('Get') and resource ('liquidity information for a token') with a scope qualifier ('across all DEXes'). It is distinguishable from pool-level siblings like get_network_pools and get_pool_analytics, but it never explicitly contrasts with those alternatives.

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?

There is no guidance on when to call this instead of get_network_pools, get_dex_info, get_pool_analytics, or compare_dex_prices. The agent must infer usage from the name alone.

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

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

With no annotations, the description carries the full disclosure burden, yet it says nothing about how signals are derived, whether they are per-timeframe, whether confidence or indicator breakdowns accompany them, or whether they should be treated as advice. "Based on technical analysis" is the only behavioral hint provided.

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?

A single front-loaded sentence with no filler — efficient, though its economy borders on under-specification rather than crispness.

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

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

No output schema and no annotations, so the description should explain the shape and trustworthiness of a signal (fields, per-timeframe behavior, caveats) but does not. For a compute-style analysis tool with three knobs, this leaves real gaps an agent cannot resolve elsewhere.

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

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

Schema coverage is 100% and each parameter already documents its accepted values and defaults, so the schema does the heavy lifting. The description adds nothing about how timeframe or risk_level change the resulting signal, so baseline 3 applies.

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

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

States a specific verb and output ("Generate buy/sell/hold signals") plus the basis ("technical analysis"), so the agent knows what it produces. However, it draws no line against close siblings such as get_technical_indicators, multi_timeframe_analysis, or get_full_analysis, which could easily overlap.

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 on when to pick this over get_technical_indicators, multi_timeframe_analysis, or get_full_analysis, and no prerequisites or exclusions. The agent must infer the choice from the name alone.

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 of disclosure. It does not state whether the tool is read-only, what data sources or timeframes are used, whether results are cached or delayed, or what the response contains, leaving significant behavioral gaps for an analysis 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 short sentence with no wasted words, but it is under-specified rather than appropriately concise. It front-loads the action but omits key context that would make the sentence more useful.

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

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

Given the complexity implied by 'multiple timeframes' and the absence of annotations or an output schema, the description is incomplete. It does not explain which timeframes are analyzed, what outputs to expect, or how to interpret the results, so an agent lacks enough context to call it confidently.

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

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

Schema description coverage is 100%, and the single parameter is documented as a 'Cryptocurrency symbol'. The description adds no meaning beyond the schema, so the baseline of 3 is appropriate for a well-documented one-parameter 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 states a verb ('Analyze') and a resource area ('trends and signals across multiple timeframes'), so the general purpose is understandable. However, it does not specify which timeframes, what signals, or how this differs from sibling analysis tools such as get_trading_signals, get_technical_indicators, or get_full_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?

There is no explicit guidance on when to use this tool versus alternatives. The description implies it is for multi-timeframe analysis, but an agent must infer that from the name and cannot tell when to choose it over get_full_analysis or get_trading_signals.

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

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

With no annotations, the description carries the full burden and discloses almost nothing: no mention of result ranking/ordering, no pagination behavior with the limit parameter, no indication of how min_volume/min_liquidity interact with query, and no note on what a result contains. "Advanced" conveys no behavioral fact.

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?

A single sentence with no wasted clauses, so it is compact. However, it is under-specified rather than concise — the words "advanced" and "with filters" occupy space without earning it, and there is no front-loaded statement of distinction.

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 4-parameter cross-network search tool with no annotations and no output schema, the description says nothing about return values, ordering, empty-result behavior, or how filters combine. The schema covers inputs, but an agent still lacks the context needed to interpret or trust the results.

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

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

Schema description coverage is 100%, so all four parameters (query, limit, min_volume, min_liquidity) are already documented in the schema. The description's only contribution is the vague word "filters," adding no syntax, format, or interaction semantics beyond the schema — baseline 3 applies.

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

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

States a verb and resource ("token search") and a scope ("across all networks"), which does partially distinguish it from search_tokens_by_network. But "advanced" and "with filters" are filler that don't say what makes it advanced or which filters are available, so the core differentiator remains opaque.

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 when-to-use or when-not-to-use guidance, and the obvious sibling search_tokens_by_network is never named. The only implied routing signal is "across all networks," which an agent must infer selects this tool when no single network is targeted.

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 behavioral burden, yet it discloses nothing beyond the one-line purpose: no return shape, no pagination/limit interaction, no indication whether results are ranked, and no note that this is a read-only lookup. The only behavioral hint is the implicit scoping to a single network.

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?

A single efficient sentence with the network scoping front-loaded and no filler. It is concise but borders on under-specified rather than maximally useful.

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 read-only search with a fully documented schema and a required network param, the definition is minimally viable. It omits what results contain, how the optional query matches, and how it relates to the advanced search sibling, leaving gaps an agent must guess at.

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

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

Schema description coverage is 100% with three params fully documented (limit with default/max, query for name/symbol, network with examples), so the schema does the heavy lifting. The description adds no parameter meaning beyond restating the network scoping already in the schema, making baseline 3 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?

States a specific verb (search) and resource (tokens) with a scope qualifier (a specific blockchain network). It does not name or distinguish itself from the sibling search_tokens_advanced, so an agent must infer the difference from the name alone.

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?

There is no guidance on when to use this instead of search_tokens_advanced, nor on prerequisites like knowing a valid network name (get_available_networks exists as a sibling but is not referenced). Usage must be inferred entirely from the name.

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