SQD

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful behavioral context by specifying what the analytics cover (block cadence, fees, SegWit/Taproot adoption, activity metrics) and hinting that the tool is network-level rather than transaction-level.

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 well-structured with headings and a strong front-loaded first sentence. Some redundancy exists across 'COMMON USER ASKS,' 'FIRST CHOICE FOR,' and 'WHEN TO USE,' but overall the content is efficiently organized and scannable for an agent.

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 read-only analytics tool with 100% schema coverage and an output schema, the description provides all necessary selection context, explicit usage guidance, and a concrete example. Nothing critical for calling this tool correctly is missing.

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

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

Schema description coverage is 100%, so the schema itself documents all 9 parameters thoroughly. The description adds a small usage example with network and timeframe, which slightly reinforces parameter usage, but it does not contribute substantial 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 first sentence names a specific verb ('Get the big picture') and a precise resource ('Bitcoin block, fee, and address activity') over a recent or explicit window. It clearly distinguishes itself from transaction-level siblings like portal_bitcoin_query_transactions by focusing on network analytics rather than raw transactions.

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

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

The description has explicit 'WHEN TO USE' and 'DON'T USE' sections, providing clear conditions such as 'You want the big picture for Bitcoin right now' and 'You need raw transactions rather than network analytics.' This directly routes an agent to the appropriate sibling tool and prevents misuse.

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

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

Annotations already declare readOnlyHint and non-destructive, so the description mainly adds useful context: it returns raw Bitcoin transaction records, supports inline inputs/outputs, and mentions UTXO envelope and response format defaults. No contradiction with annotations exists.

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

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

The description is well-structured with headers, front-loaded purpose, and compact examples. A minor redundancy exists between 'COMMON USER ASKS' and 'WHEN TO USE', but overall it is efficient for a 12-param 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?

The description is complete for an agent to decide when and how to invoke the tool: purpose, when to use, when not to use, and concrete example payloads are all present. The output schema exists, so the return format does not need to be described in prose.

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

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

Schema coverage is 100%, so the schema already documents each parameter. The description adds value by showing example payloads, clarifying that include_inputs/include_outputs attach data inline, and noting the response_format default to 'compact' for chat-friendly output.

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

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

The description opens with a specific verb and resource: 'Query raw Bitcoin transactions' and clarifies optional behavior of attaching inputs and outputs inline. This clearly distinguishes it from analytics, wallet summary, and network tools among siblings.

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

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

The description includes explicit 'WHEN TO USE' and 'DON'T USE' sections, giving direct guidance on when to select this tool over other alternatives. Examples further clarify concrete invocation scenarios such as recent transactions and attaching inputs/outputs.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by emphasizing these are raw replica-command actions rather than derived fills/analytics, plus an ADVANCED warning and a concrete example invocation.

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

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

The description is well-organized with clear headings, front-loads the core query purpose, provides a concrete example, and has no filler. Every section earns its place, and the example is directly actionable.

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 13-parameter schema with full parameter descriptions, a rich output schema, and annotations covering read-only safety, the description provides sufficient orientation. It adds selection guidance, exclusions, and an example, so nothing critical is missing for an agent to invoke this tool correctly.

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

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

Input schema coverage is 100%, with every parameter individually described. The description adds a useful example JSON and mentions action types like orders, cancels, and leverage updates, but it does not substantially enrich parameter semantics beyond what the schema already provides.

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

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

Description states a specific verb and resource: 'Query Hyperliquid replica-command actions such as orders, cancels, and leverage updates.' It also differentiates from sibling tools by noting this is for raw order-action events rather than fills or analytics, making it easy to distinguish.

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?

WHEN TO USE and DON'T USE sections explicitly state the usage context: debugging Hyperliquid replica-command records and needing raw order-action events. It also names excluded cases ('fills and analytics are usually the better fit'), giving clear alternative routing.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: it flags the tool as 'ADVANCED,' emphasizes 'raw block records directly,' and clarifies that this is a debugging tool rather than a general-purpose data access tool. It does not deeply describe pagination or output quirks, but the output schema and parameter descriptions partially cover those.

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 tightly organized into short labeled sections: ADVANCED, COMMON USER ASKS, WHEN TO USE, DON'T USE, and EXAMPLES. Every section earns its place, there is no repetition of schema details, and the most operationally important guidance is front-loaded. It is longer than a single sentence but highly scannable 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 11 optional parameters, rich schema descriptions, an output schema, and annotations, the description is largely complete: it states when to use it, when not to use it, supported networks, and gives a realistic example. The only minor gap is that it does not clarify which parameters are effectively required when not resuming with a cursor, though the example and schema hints mitigate this.

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

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

The input schema has 100% parameter description coverage across all 11 parameters, so the schema carries the semantic load. The description contributes an example showing network, timeframe, and limit, which helps illustrate usage, but it does not add important meaning beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description opens with 'ADVANCED: Query raw block records directly for EVM, Solana, or Bitcoin,' which names a specific verb, a clear resource, and supported networks. It differentiates itself from sibling tools by stating it returns raw block records 'instead of transactions, logs, or summaries,' so an agent can distinguish it from query_logs, query_transactions, and analytics 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 'WHEN TO USE' and 'DON'T USE' sections, including concrete conditions like 'debugging Portal coverage or block-level fields' and directing normal end-user questions to 'recent activity, time series, or raw transaction tools first.' It also includes a concrete example ('Recent Base blocks') with actual parameter values, giving the agent a clear model invocation.

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

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

Annotations already mark it read-only and non-destructive, and the description adds that it resolves to the 'nearest indexed block or slot' and lets you 'inspect exact versus estimated' resolution. This gives useful behavioral nuance beyond the schema and annotations, without contradicting them.

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?

Every section earns its place: a one-sentence purpose, examples, explicit when/don't guidance, and fully-formed JSON examples. The key purpose and usage guidance are front-loaded, and the formatting makes the content scannable despite its length.

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

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

A direct resolution tool with an output schedule, full schema coverage, and annotations already present; the description supplies the missing user-facing context: common asks, use cases, exclusions, and concrete examples. Nothing critical for selecting and invoking the tool is absent.

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

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

Schema descriptions cover both parameters fully, so the baseline is 3, but the description adds concrete example values and expected JSON for network ('base-mainnet','polkadot') and timestamps ('1h ago','ISO 8601'). These examples clarify how the otherwise generic 'network name or alias' should be used in practice.

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 operation: 'Resolve a timestamp to the nearest indexed block or slot,' which clearly identifies the tool's purpose and resource. It distinguishes itself from general query tools by framing this as an ADVANCED, low-level resolution utility, though it does not explicitly separate itself from the sibling portal_debug_query_blocks.

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?

WHEN TO USE and DON'T USE sections give explicit decision guidance: use for debugging timestamp windows or manual block-range queries, and avoid when the user simply needs time-based queries because most public tools already accept natural timestamps. It does not name a specific sibling alternative, but the guidance is clear enough for an agent to route the call.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is handled. The description adds useful behavioral context: it returns aggregates/ranked entities, is network-wide, and is an analytics-style overview rather than a raw record list. Enough is disclosed for a read-only analytics 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 uses clear section headers and concise bullets, front-loads the core purpose, and includes a compact example. Each section earns its place and the overall structure is easily scannable for an agent.

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 9 optional parameters, output schema, and read-only annotations, the description is complete enough: it states what the tool does, when to use it, what not to use it for, and provides a working example call. The agent has all the orientation needed beyond the rich schema.

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

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

Schema description coverage is 100%, so the input schema already documents all nine parameters. The description adds a illustrative example with network, timeframe, and limit, which is helpful, but it does not materially extend the parameter meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Get the big picture for network-wide EVM activity with ranked contracts and compact overview metrics.' It clearly differentiates this as an analytics/overview tool rather than a raw record or contract-specific tool, and the DON'T USE section reinforces the boundary.

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

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

Provides explicit WHEN TO USE bullet and a clear DON'T-USE case ('chart buckets over time rather than ranked entities'), plus a concrete example. It does not name a specific sibling tool as the replacement alternative, so the guidance is strong but not fully explicit about which tool to choose instead.

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

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

Annotations already establish readOnlyHint, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds behavioral context by clarifying that this returns a contract-level summary rather than raw records, and mentions optional event activity and top callers.

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 well-structured with clear sections and front-loaded purpose. Some redundancy exists between 'FIRST CHOICE FOR' and the first 'WHEN TO USE' bullet, but overall it remains readable 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 a rich input schema with 100% coverage, an output schema, and safety annotations, the description supplies the missing use-case context, exclusions, and a concrete example. Nothing essential for selecting or invoking this tool is missing.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds a useful example with network, contract_address, and timeframe, but does not need to add much parameter-level detail.

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 states a specific verb and resource: summarize what one specific contract has been doing lately, including interactions, unique callers, and optional event activity. It differentiates from sibling raw log/transaction tools by emphasizing a contract-centric, aggregated activity summary.

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

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

Provides explicit WHEN TO USE conditions and a clear DON'T USE section covering raw logs/transactions and general network activity. This effectively routes an agent to the right tool without needing to inspect 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?

Annotations already mark the tool as read-only and non-destructive. The description goes beyond that by explaining that the tool returns the create trace and parent transaction, supports well-known aliases, requires a bounded window, and can scan latest-first or earliest-first. This gives the agent a solid behavioral model of what the tool does and what it returns.

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 longer than average but well-structured with scannable sections: summary, common asks, first choice, when/don't use, and examples. Each section earns its place by covering a distinct aspect of selection or invocation, though a few phrases are slightly redundant.

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 11 parameters, an output schema, read-only annotations, and a large sibling list, the description is highly complete. It provides real examples, boundary conditions for old contracts, alias handling, and explicitly contrasts with general contract activity. Nothing essential for an agent to invoke this tool correctly is missing.

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

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

The input schema has 100% parameter coverage, so the baseline is 3. The description adds meaningful semantic guidance through examples showing how to combine contract aliases, from_block, to_block, scan_order, and search_depth_blocks, which helps the agent construct valid calls more confidently than schema alone.

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

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

The description opens with a specific verb and resource: 'Locate the create trace and parent transaction that deployed a specific EVM contract address within a bounded window.' It clearly distinguishes this from sibling tools like portal_evm_get_contract_activity by stating it is a deployment lookup rather than general contract activity.

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 includes explicit 'WHEN TO USE' and 'DON'T USE' sections, giving an agent clear conditions for selecting this tool and excluding alternatives. It also names the key alternative behavior (general contract activity) and warns when the tool should not be used, such as when no block/time hint exists for an old contract.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, and the description does not contradict them. It adds useful behavioral context beyond annotations: the data is event-derived from DEX swap sources, output includes a trade tape, and examples clarify that Uniswap v4 uses pool_id rather than a per-pool contract address.

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 longer than average but well-structured with COMMON USER ASKS, WHEN TO USE, DON'T USE, and EXAMPLES sections. Each section earns its place, and the core purpose is front-loaded in the first sentence. The formatting makes it easy to scan for both selection and invocation.

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 24 parameters, 0 required fields, a fully documented schema, and an output schema; the description complements this by explaining when to use the tool, when not to, and providing realistic invocation examples. Nothing essential for correct selection or basic invocation is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds valuable parameter-selection examples: v4 uses pool_id, Aerodrome uses price_in='token1', and include_recent_trades toggles the trade tape. These examples help an agent map user intent to the correct parameter combinations beyond the schema's individual descriptions.

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

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

The description opens with a specific verb and resource: 'Build chart-ready EVM OHLC candles plus a recent trade tape from supported DEX event sources.' It names the concrete source families (Uniswap v2-style, v3/v4, Aerodrome Slipstream) and distinguishes the tool from scalar time-series tools. Common user asks and examples reinforce the exact scope without ambiguity.

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 WHEN TO USE and DON'T USE sections give explicit context: use it for candle charts and trade tapes, avoid it for counts or scalar metrics. It does not name specific sibling tools such as portal_get_time_series or portal_evm_get_analytics as alternatives, so the guidance is clear but not tool-explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered and the 'Query' language is consistent with them — no contradiction. The description adds useful behavioral context beyond annotations: decoded output shape (decoded_log.decoded.token_id), scan-order semantics for first/last searches, and the bounded-window scanning strategy. It doesn't cover cursor pagination behavior or rate limits, but with annotations carrying the safety burden and the schema carrying parameter-level performance warnings, this is a minor 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?

Though longer than average, every section earns its place: COMMON USER ASKS anchors the tool to real queries, FIRST CHOICE FOR and DON'T USE differentiate from siblings, WHEN TO USE gives actionable criteria, and EXAMPLES provide copy-paste-ready payloads. The core definition is front-loaded in the first sentence, and the header-based structure makes the content skimmable for an agent.

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 25-parameter tool with an output schema present, the description covers all essential context: what the tool does, when it's the right choice, when it's not, how to construct the three main user ask patterns, and the exact recipe for the ERC721 mint lookup. The output schema handles return-value documentation, so its absence from the description is not a gap. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description raises it by showing real parameter combinations in four worked examples (token_symbols+event+timeframe, from_block/to_block+addresses+topic1+scan_order+decode+include_transaction+limit, and topic0+decode) that teach the agent how parameters interact for each user intent. This exceeds what the schema alone 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 opening sentence is a specific verb+resource statement: 'Query raw EVM logs with address/topic filters, common event aliases, earliest/latest scanning, and optional inline decoding.' It names the exact scope and mechanism. It differentiates from siblings by stating it's for 'exact event evidence rather than wallet or transaction summaries' and explicitly says token-transfer queries are better served elsewhere.

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 contains explicit WHEN TO USE (five concrete criteria), DON'T USE (names the token-transfer tool as the alternative), and FIRST CHOICE FOR sections. It even provides a canonical recipe for the latest-ERC721-mint use case with exact parameter settings. This is textbook-level routing guidance with no ambiguity 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?

Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it resolves token symbols, supports 'earliest' scan order for first-transfer questions, and emphasizes speed and bounded windows. It does not fully describe pagination behavior, but the output schema and cursor parameter partially cover that.

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

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

The description is front-loaded with a one-sentence summary, then uses clear labeled sections: COMMON USER ASKS, WHEN TO USE, DON'T USE, and EXAMPLES. Every section earns its place and the formatting makes it easy to scan for decision-making.

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 read-only, open-world tool with 15 optional parameters, an output schema, and 100% schema coverage, the description provides complete contextual guidance. It covers when to use it, when not to, example payloads, and the key behavioral nuances like scan_order and symbol resolution. No critical guidance for correct usage is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by providing concrete example parameter sets for common user asks, such as using token_symbols, timeframe, scan_order, and limit together. This helps an agent map natural-language requests to actual parameter combinations beyond what the schema alone 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?

The description states a specific verb and resource: 'Query token-transfer activity on EVM'. It also distinguishes itself from the sibling query_logs by noting it works without needing to remember Transfer event signatures, so an agent can tell it apart from generic EVM log queries.

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 has explicit 'WHEN TO USE' and 'DON'T USE' sections. It gives concrete conditions such as needing ERC-20 transfer activity filtered by token/sender/recipient, tracing stolen or suspicious transfers, and wanting the fastest raw transfer query, while excluding arbitrary event log queries.

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

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

Annotations already declare the tool safe/read-only, and the description adds useful behavior: optional logs/traces/state-diff context, evidence pivots, failed-call investigation, and bounded aggregation/ranking semantics. It does not contradict the readOnlyHint/openWorldHint/destructiveHint annotations, though some operational traits (client-side scan caps, pagination) appear mainly in schema parameter descriptions.

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 well structured with COMMON USER ASKS, WHEN TO USE, DON'T USE, and EXAMPLES, and the core definition is front-loaded. There is minor redundancy between the common-asks bullets and when-to-use bullets, but the length is justified by the tool's 35 parameters.

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 complex 35-parameter tool with 100% schema coverage, an output schema, and read-only annotations, the description covers use cases, exclusions, and worked examples without needing to restate return values. Nothing essential for selecting or invoking the tool is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds value by mapping user intents to parameter combinations in EXAMPLES (e.g., network+timeframe+limit for recent Base transactions, and from_block+transaction_type+scan_order+field_preset for the first EIP-2930 transaction). These examples show composition and realistic values that the schema alone does not convey.

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

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

Opens with 'Query raw EVM transactions' -- a specific verb, resource, and scope -- and adds optional logs, traces, state-diff context, and evidence pivots for transaction-level investigations. The DON'T USE section further distinguishes it from convenience feed/wallet-summary 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?

WHEN TO USE provides seven concrete triggers (first typed transaction, top-N by gas/value, aggregate senders/receivers, token-symbol calls, common method names), and DON'T USE gives two clear exclusions. However, alternatives are referred to only generically ('convenience tools', 'quick recent feed or wallet-level summary') rather than by sibling tool name, leaving some routing 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with them. It adds useful nuance by clarifying this returns the indexed head block or slot, not live network status, and supports latest/finalized variants.

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 core behavior is front-loaded and the description is well-organized with clear headers and examples. There is slight redundancy between COMMON USER ASKS and the examples, but it remains efficient and scannable.

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, strong annotations, 100% parameter coverage, and clear when/when-not guidance, the description fully covers what an agent needs to select and call this tool. The examples resolve any ambiguity around the required 'network' and optional 'type'.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds concrete example payloads for latest and finalized heads, making the enum and network parameter semantics tangible beyond the bare schema descriptions.

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

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

The description states a specific verb and resource: 'Get just the latest indexed head block or slot for a network.' It clearly supports latest vs finalized and distinguishes itself from broader analytics or block-building tools in the sibling list.

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

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

Provides explicit WHEN TO USE and DON'T USE sections, plus 'FIRST CHOICE FOR' context, so an agent knows when to invoke it. It does not name a specific alternative tool for the excluded cases, but the boundaries are clear enough for correct 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?

Annotations already mark this readOnly and non-destructive, so the description only needs to add behavioral context beyond that. It adds useful behavior: returns indexing freshness, lag, heads, available tables, and chain-family/real-time status, making clear what kind of answer the agent should expect. No contradiction with annotations.

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

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

Although the description uses several labeled sections, each section earns its place by adding distinct selection or invocation guidance. The core behavior is front-loaded in the first line, and there is no filler or repetition.

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

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

For a single-parameter, read-only tool with an output schema and strong annotations, the description covers purpose, usage context, exclusions, and a worked example. An agent has everything needed to select and invoke it correctly without opening the schema.

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

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

The schema fully documents 'network' as a name/alias, so the baseline is 3. The description adds a concrete mapping from a natural-language question ('Is Base caught up?') to a valid parameter object ({"network":"base-mainnet"}), which clarifies the expected value format 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 leads with a concrete task ('answer is this network caught up?') and names the resource: indexing head, lag, tables, and capabilities for a single network. It distinguishes itself from sibling tools like portal_get_head and portal_list_networks by scoping to one network and naming what it does not do.

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

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

It provides explicit 'WHEN TO USE', 'DON'T USE', 'FIRST CHOICE FOR', and a common user ask with an example. The 'DON'T USE' exclusion ('only need the latest block or slot number') gives clear negative selection criteria and implicitly points toward a sibling 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?

Annotations already declare readOnlHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavior: chronological paging, newest activity first, bounded recent evidence timeline, and cross-network coverage. No contradiction with annotations.

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

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

Well-organized and front-loaded with a clear one-sentence summary. Slight redundancy exists: COMMON USER ASKS repeats the examples almost verbatim, and FIRST CHOICE FOR overlaps with WHEN TO USE, so not every sentence earns its place.

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

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

The descripton fully covers when to use, when not to use, supported networks, typical parameter values, and paging concept. With 100% schema coverage and an output schema present, nothing essential for selecting and invoking this tool is missing.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value beyond the schema with concrete example payloads showing valid network names like 'base-mainnet' and 'hyperliquid-fills', and demonstrates how timeframe and limit are commonly combined.

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

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

States a specific verb and resource ('Get a simple recent-activity feed across EVM, Solana, Bitcoin, or Hyperliquid') and clearly distinguishes itself from raw query tools via the DON'T USE section. The scope is unambiguous even without naming specific siblings.

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

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

Provides explicit WHEN TO USE and DON'T USE sections, plus common user asks and examples. It names alternatives by category (raw VM-specific query tools, charting tools) and gives concrete conditions like needing raw logs or a time-series chart.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true). The description adds genuinely useful behavioral context beyond that: the tool returns aggregated 'chart-ready metric buckets' rather than raw records, defaults to a 6h interactive window, and supports compare-previous windows and grouped EVM contract trends. These are behavioral traits an agent cannot infer from annotations alone.

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 well-structured with labeled sections (COMMON USER ASKS, FIRST CHOICE FOR, WHEN TO USE, DON'T USE, EXAMPLES) that are easily scannable by an agent. The lead sentence front-loads the core purpose. Minor deduction because FIRST CHOICE FOR and WHEN TO USE partially overlap in content, adding slight redundancy.

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

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

For an 11-parameter tool with an output schema and safety annotations, the description covers the key decision paths: what it returns (aggregated buckets), default window, when to use it, when not to use it, and two worked examples. A small gap remains: it does not disambiguate from sibling portal_evm_get_contract_activity for address-scoped contract trends, though the schema's address/group_by parameters partially cover that ground.

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 rich per-parameter descriptions (e.g., mode's fast/deep distinction, duration's natural phrases), so the baseline is 3. The EXAMPLES section adds value beyond the schema by showing complete, realistic parameter combinations: network+metric+duration+interval for a 15m bucket, and the same plus compare_previous=true for period comparison. This demonstrates how parameters work together, which static schema entries do not.

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 lead sentence states a specific verb and resource: 'Build simple activity charts and other time-series views across supported VMs.' It differentiates from siblings by scoping to aggregated, chart-ready metric buckets and explicitly excluding OHLC output and raw record lists, which maps directly to sibling tools like portal_evm_get_ohlc and portal_evm_query_transactions.

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

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

The description has explicit WHEN TO USE and DON'T USE sections with concrete conditions: chart-ready metric buckets over time, compare current vs previous period, and exclusions for raw record lists and DEX pool candles/OHLC. It also states a clear default behavior (6h interactive window) that agents should know before calling.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the description is not required to repeat those. It adds value by framing output as structured, directly observable data for further reasoning and emphasizing summarization behavior. However, it doesn't clearly disclose aggregation details, pagination/cursor behavior, or exactly what 'shared overview' contains, leaving some behavioral nuance to inference.

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 well-organized with clear section headers, front-loads the core purpose in the first sentence, and uses bullet-style sections for rapid scanning. It is longer than strictly minimal, but each section earns its place by aiding agent comprehension. The corrupted VOID format instruction sits after the main description and does not undermine the structure, though the description's own length is justified.

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 and 100% parameter docs, so the description does not need to explain return values. It covers selection guidance, user intents, examples, and exclusions, which is rich contextual guidance. Given the tool's moderate complexity and existing schema/annotation coverage, the only minor gap is absent mention of output shape semantics beyond the corrupted VOID, but this is adequately covered by the output schema signal.

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 input schema already documents all 11 parameters thoroughly. The description adds usage context through concrete examples showing network, address, and timeframe together, and implies that address/network become optional when continuing with a cursor. However, it doesn't compensate further for nuance like limit_per_type's capped-at-4 behavior or response_format differences.

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 ('Summarize wallet activity and fund flow') and identifies the exact resource and scope: shared overview, asset movement, counterparties, evidence pivots, and follow-up filters. It clearly distinguishes itself from sibling raw query tools by emphasizing high-level summarization over raw records, so an agent can discriminate it from portal_evm_query_transactions, portal_solana_query_transactions, or portal_get_recent_activity without opening schemas.

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

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

Explicit WHEN TO USE and DON'T USE sections provide strong selection guidance, plus COMMON USER ASKS and FIRST CHOICE FOR context. It clearly names exclusions (raw record retrieval) and the exact use cases (suspicious wallet triage, stolen funds, exploit counterparty). This is comprehensive, actionable guidance for agent 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety profile is covered. The description adds genuine behavioral value by disclosing that the tool performs server-side aggregation ('grouped aggregate sections without stitching raw fills together yourself') and returns a big-picture snapshot rather than record-level data. It could additionally characterize pagination behavior behind the cursor, but the schema already documents cursor semantics.

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?

Despite its length, every section earns its place: the core statement is front-loaded, COMMON USER ASKS maps intents to queries, WHEN/DON'T USe provides routing rules, and EXAMPELes give ready-to-use payloads. The headers make it scannable, and there is no filler or repetition of schema 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 complexity (9 parametrs, 27 sibling tools, output schema present), the description is highly complete: it covers purpose, user intents, exclusion boundaries, and worked examples. The output schema covers return-value expectations, and 100% schema coverage handles parametr semantics. Minor remaining gap is that differentiation from the other network get_analytics siblings (bitcoin, evm, solana, substrate) relies on the tool name and one adjective rather than explicit contrast, but the absence of required parametrs makes invocation failure unlikely.

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 carries the parameter documentation burden and the baseline is 3. The description adds modest value with concrete EXAMPLES mapping the same minimal payload ({"network":"hyperliquid-fills","timeframe":"1h"}) to two distinct user intents, demonstrating that defaults suffice. It does not, however, elaborate on coin, response_format, or mode beyond what the schema already 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?

The description opens with a specific verb+resource: 'Get the big-picture Hyperliquid fill analytics with top traders, volume by coin, fees, and PnL.' It clearly separates this tool from siblings by emphasizing 'big-picture' and 'grouped aggregate sections' in contrast to raw fills (portal_hyperliquid_query_fills) and OHLC candles (portal_hyperliquid_get_ohlc), which are explicitly called out. The COMMON USER ASKS section reinforces the intent with concrete phrasings an agent will hear.

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 WHEN TO USE and DON'T USE sections. It states use cases (network-level fill analytics, top traders, volume by coin, fees/PnL, grouped aggregates without stitching raw fills) and exclusions (individual fill records, OHLC candles). While sibling tools aren't named by identifier, the conditions unambiguously route to query_fills and get_ohlc, giving an agent clear decision criteria.

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

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

Annotations already cover read-only and non-destructive behavior, so the description only needs to add context beyond that. It adds meaningful behavioral detail: candles are derived from fills, are chart-ready, and include OHLC, volume, and VWAP. This goes beyond the structured annotation fields.

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 tightly organized into labeled sections with no wasted words. The core purpose is stated in the first sentence, and the example is compact and directly 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 read-only OHLC tool with a rich input schema, output schema, and clear annotations, the description covers the essential decision-making context: what it produces, when to use it, when not to, and a representative example. Nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already documents all eight parameters in detail. The description adds a concrete example mapping a common user ask to parameters and shows a realistic JSON payload, which is helpful but not a substantial semantic addition 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 names a specific verb and resource: "Build chart-ready Hyperliquid trade OHLC candles." It clearly distinguishes from siblings by emphasizing chart-ready data, fixed buckets, auto intervals, and use of fills, so an agent can tell it apart from portal_hyperliquid_query_fills and portal_get_time_series.

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 WHEN TO USE and DON'T USE sections are explicit and actionable, stating to use this tool for one-coin candle data and to avoid it for raw fills or scalar time-series buckets. This effectively routes the agent to alternatives without ambiguity.

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

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

Annotations already cover read-only and non-destructive behavior. The description adds useful context that it returns raw individual fills rather than aggregation and includes fee/PnL/builder fields. However, it doesn't disclose pagination/cursor behavior, response cap, or response_format consequences, which remain in the schema.

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?

Well-organized with clear sections and a front-loaded main sentence. The 'COMMON USER ASKS' and 'EXAMPLES' sections are slightly redundant around 'Recent BTC fills', keeping it short of a 5, but there is 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?

For an 18-parameter read-only query tool with a rich input schema and an output schema, the description gives purpose, use conditions, exclusions, and a practical example. Parameter relationship nuances like timeframe vs. block ranges or cursor continuation are left to the schema, which is acceptable.

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 every parameter already documented. The description adds a small amount by grouping common filters and showing one concrete example, but doesn't materially expand parameter meaning, so baseline 3 is appropriate.

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

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

Description opens with a specific verb plus resource: 'Query raw individual Hyperliquid fills' and lists the information included (trader, coin, fee, PnL, builder). It also distinguishes itself from siblings via 'DON'T USE' for aggregates/candles, so an agent can tell it apart from analytics and OHLC 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?

Has explicit WHEN TO USE and DON'T USE sections that state when raw fill records are appropriate and when not to use the tool (big picture, top traders, grouped aggregates, candles). Lacks named alternative tools, so it doesn't fully meet the 5-level bar.

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

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

Annotations already mark it read-only and non-destructive; the description adds that it is a catalog/discovery lookup covering multiple VM families, supports search by name/alias/chain ID, and can filter by real-time availability. This context explains what the tool returns beyond the safety profile without contradicting the annotations.

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

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

Structured section headers (COMMON USER ASKS, FIRST CHOICE FOR, WHEN TO USE, DON'T USE, EXAMPLES) make each part skimmable, and the opening sentence states the core purpose immediately. There is mild redundancy between the common asks and examples, but no wasted or irrelevant 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?

With a full output schema, 100% parameter documentation, and annotations covering read-only/open-world safety, the description supplies the missing selection context: when to use, when not to use, and realistic invocation examples. Nothing needed to call the tool correctly is absent.

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 covers all six parameters (100%), so the baseline is 3; the description adds concrete parameter semantics via examples like {'query':'base','limit':10} and {'vm':'solana','network_type':'mainnet'}, showing valid values and combinations that clarify the schema's 'vm' and 'network_type' fields.

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 opens with a specific verb and resource: 'Find the right network or chain name to use across EVM, Solana, Bitcoin, Substrate, and Hyperliquid.' It also declares itself 'FIRST CHOICE FOR: finding the correct network before any other query,' which clearly separates it from sibling data-query tools.

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

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

Provides explicit 'WHEN TO USE' and 'DON'T USE' sections: use when unsure of network name/chain/alias or when filtering by VM family, network type, or real-time availability; don't use when you already know the exact network and want live data. The 'FIRST CHOICE' positioning and examples route the agent to this tool before other portal_* queries.

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

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

Annotations already cover read-only and non-destructive behavior. The description adds meaningful behavioral context beyond annotations: 'ambiguity kept explicit', 'source-backed token address', and the notion of checking which token-list addresses a symbol maps to. This helps the agent anticipate multiple matches or ambiguous resolution outcomes.

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 structure is highly organized with clear sections and front-loaded purpose, making the key behavior immediately visible. There is mild redundancy between 'FIRST CHOICE FOR' and 'WHEN TO USE', as several bullets repeat the same conditions, but the overall length is justified by the tool's breadth of entity kinds.

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

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

The description is complete for a read-only resolution tool: it covers supported entity kinds, common user asks, when to use, when not to use, and includes multiple fully specified JSON examples. An output schema exists, so omitting return-value details is acceptable. No important operational gaps remain.

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 all four parameters already have descriptions. The description adds value with concrete example payloads for different kinds and networks, plus guidance that queries can be fuzzy aliases (e.g., 'bored apes' for BAYC) rather than exact symbols. This enriches semantics beyond the schema definitions.

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

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

Purpose clarity is excellent: it states a specific verb and resource ('Resolve user-facing blockchain entities into query-ready identifiers') and includes concrete examples. It is clearly differentiated from sibling query tools as the pre-query resolution step.

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 dedicates 'WHEN TO USE' and 'DON'T USE' sections, giving concrete conditions such as resolving a symbol before querying logs or transfers, and excluding cases where an exact address or filter is already known. This provides actionable routing guidance without requiring the agent to infer.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds value by framing the tool as a 'big picture' / 'network health snapshot' rather than a raw data dump, which helps set expectations about the response granularity. Performance caveats like include_programs being slower live in the schema, so the description's behavioral contribution is modest but meaningful.

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 longer than typical but earned its length: every section ('COMMON USER ASKS', 'FIRST CHOICE FOR', 'WHEN TO USE', 'DON'T USE', 'EXAMPLES') serves a distinct purpose with no filler. The core purpose sentence is front-loaded, and the structured headings make scanning fast for an agent.

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 10 parameters, a rich output schema, and annotations already covering safety, the description provides all necessary decision context: what the tool returns, when it is the first choice, when not to use it, and concrete example calls. The remaining details (parameter formats, defaults, pagination) are fully covered by the schema and output schema, so nothing needed for correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already documents all 10 parameters thoroughly, giving a baseline of 3. The description adds concrete example payloads for common asks ('network':'solana-mainnet','timeframe':'1h' and with include_programs:true), which demonstrates realistic parameter combinations and adds meaning beyond the schema's individual descriptions.

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

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

The description opens with a specific verb and resource: 'Get the big picture for Solana throughput, fees, wallet activity, and optional top-program usage.' It clearly differentiates from raw-record siblings by stating it provides analytics rather than raw transaction/instruction records, and the 'DON'T USE' section explicitly rules out chart buckets and raw records.

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 'FIRST CHOICE FOR' and 'WHEN TO USE' sections that state the tool is for Solana network snapshots and aggregate analytics, and a 'DON'T USE' section that excludes chart buckets and raw transaction/instruction records. Though sibling tools are not named, the categories directly map to the raw-query siblings like portal_solana_query_transactions and portal_solana_query_instructions, giving clear routing guidance.

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