SQD Portal

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

No annotations are provided, so the description must carry the behavioral disclosure burden. It does convey a read-only network analytics nature and the data categories included, but it does not mention return format, pagination, performance caveats (though one parameter description notes extra queries), or any potential side effects.

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

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

The description is well-structured with distinct sections (COMMON USER ASKS, FIRST CHOICE FOR, WHEN TO USE, DON'T USE, EXAMPLES) and remains focused. Each sentence contributes to selection or invocation guidance; the slight repetition of 'big picture' is acceptable for emphasis.

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 9-parameter analytics tool with no output schema and no annotations, the description covers purpose, usage boundaries, and a concrete example, and the schema handles parameter details. It falls slightly short of 5 because it doesn't describe expected output structure or note parameter exclusivity (e.g., from_block vs timeframe).

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%, establishing a baseline of 3. The description adds value beyond the schema with an example call and clarifies the 'recent or explicit window' concept, which helps interpret timeframe vs. block/timestamp parameters.

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

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

The description opens with a specific verb and resource: 'Get the big picture for Bitcoin block, fee, and address activity over a recent or explicit window.' It clearly distinguishes this analytics tool from raw transaction queries by stating 'DON'T USE... raw transactions rather than network analytics.'

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 bullets, a DON'T USE exclusion naming the sibling tool type, and an example. This gives an agent clear decision criteria against portal_bitcoin_query_transactions and other siblings.

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

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

No annotations are provided, so the description must carry the burden of disclosing behavioral traits. It describes a 'query' operation and notes optional inline attachment of inputs/outputs, which implies a non-destructive read. However, it does not explicitly state that the tool is read-only, nor does it mention rate limits or pagination behavior beyond what the schema covers.

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 opens with a crisp one-sentence summary, then organizes additional guidance into labeled sections (COMMON USER ASKS, WHEN TO USE, DON'T USE, EXAMPLES). Each section is purposeful and concise, with no redundant or filler 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 tool's 12 optional parameters and no output schema, the description provides useful situational guidance and examples. However, it omits a description of the return structure (e.g., what 'compact' vs 'full' response formats produce). The schema covers parameter semantics well, and the examples illustrate typical usage, so the description is fairly complete but not exhaustive.

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 value by providing example JSON payloads that show how to combine parameters (e.g., setting both include_inputs and include_outputs to true) and how to use network/timeframe/limit together. This goes beyond the schema's individual field descriptions.

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

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

The description clearly states the tool queries raw Bitcoin transactions with optional inline input/output attachment. This specific verb+resource+scope distinguishes it from other chain-specific transaction tools (e.g., portal_evm_query_transactions) by explicitly naming Bitcoin.

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, providing clear context for when to invoke this tool and when to avoid it (e.g., for a quick wallet or network summary). Although no specific alternative tool names are mentioned, the guidance effectively sets expectations for raw transaction queries versus summaries.

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

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

No annotations are provided, so the description must convey behavior. It clarifies that this is a query/read tool and returns 'raw order-action events,' but it does not mention pagination, whether filters are required, or any performance caveats. The 'ADVANCED' tag adds a small signal, but the behavioral disclosure is only partial.

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 'ADVANCED' and purpose, then structured into COMMON USER ASKS, WHEN TO USE, DON'T USE, and EXAMPLES. Each section is short and every sentence provides selection-relevant value.

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

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

For a complex tool with 13 optional parameters and no output schema, the description provides useful context: use cases, exclusions, and a concrete example. It does not describe return fields or default behavior when no filters are provided, but the schema covers parameter defaults and the purpose is clearly scoped.

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?

All 13 parameters have rich descriptions in the schema (100% coverage), so the baseline is 3. The description adds an example with network, timeframe, and limit, but does not elaborate on parameter meaning beyond the schema. This is adequate but not enhanced.

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+resource: 'Query Hyperliquid replica-command actions such as orders, cancels, and leverage updates.' It also distinguishes from siblings by noting these are 'raw order-action events instead of fills or analytics,' making the scope clear.

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 says use when 'debugging Hyperliquid replica-command records' and needing 'raw order-action events instead of fills or analytics,' and warns not to use if you only need 'public trading activity' because 'fills and analytics are usually the better fit.'

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 behavioral disclosure. It implies a read-only low-level operation ('query raw block records directly') and provides context about debugging, but it does not disclose response format, pagination behavior, rate limits, permissions, or any operational caveats. The 'ADVANCED' flag hints at complexity but not specific behaviors.

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

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

The description is well-structured with clear headers (ADVANCED, COMMON USER ASKS, WHEN TO USE, DON'T USE, EXAMPLES) and is front-loaded with the core purpose. Every section is concise and purposeful, making it easy for an agent to scan and extract key information without excess 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?

The tool is complex with 11 parameters, no output schema, and no annotations. The description covers usage guidance, exclusions, and an example, but does not explain the structure of the response or what 'raw block records' contain. Given the debug-oriented nature, this is adequate, but the lack of return-value description leaves a gap for an AI agent that needs to interpret 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?

The input schema has 100% description coverage for all 11 parameters, so the schema already documents them thoroughly. The description adds value with a concrete example ('Recent Base blocks: {"network":"base-mainnet","timeframe":"1h","limit":5}'), which clarifies parameter combinations and usage in a common scenario. This goes beyond the schema baseline.

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

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

The description opens with 'Query raw block records directly for EVM, Solana, or Bitcoin,' clearly specifying the verb (query), resource (raw block records), and scope (multiple chains). It explicitly distinguishes itself from sibling tools like portal_evm_query_transactions and portal_solana_query_transactions by focusing on block-level data, and the 'ADVANCED' tag signals its debug-oriented purpose.

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

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

The description provides explicit 'WHEN TO USE' and 'DON'T USE' sections. It states to use when debugging Portal coverage or needing raw block records instead of transactions/logs/summaries, and advises against using for normal end-user questions, instead preferring recent activity, time series, or raw transaction tools. This is textbook usage differentiation.

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

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

With no annotations, the description carries the full burden. It explains the core behavior (nearest indexed block/slot) and hints at exact versus estimated resolution, but it does not disclose output structure, network limitations, error behavior, or confirm it is a read-only operation. This is adequate but not rich.

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

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

The description is well-organized with clear sections (ADVANCED, COMMON USER ASKS, WHEN TO USE, DON'T USE, EXAMPLES). Every section adds distinct value, and the most important information is front-loaded in the first sentence.

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

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

Given the tool's simplicity (2 required parameters, no output schema), the description is remarkably complete: it states what it does, when to use it, when not to use it, and provides two illustrative examples. No critical context is missing for an agent to select and invoke it correctly.

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

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

The schema already fully documents both parameters, so the baseline is 3. The description adds value with concrete examples showing network aliases ('base-mainnet') and relative timestamp syntax ('1h ago'), which clarifies real-world usage beyond the generic 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 opens with a specific verb and resource: 'Resolve a timestamp to the nearest indexed block or slot.' It clearly distinguishes this from siblings like portal_debug_query_blocks by framing it as timestamp-to-block resolution and mentioning manual block-range query building.

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, with concrete use cases like debugging timestamp windows and a direct alternative ('most public tools already accept natural timestamps directly'). This gives the 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?

No annotations are provided, so the description carries the full burden. The verb 'Get' conveys a read-only operation, and the description discloses the return shape (ranked contracts and overview metrics), but it does not explicitly state safety characteristics, data freshness, or the performance implications of 'fast' vs 'deep' mode, which the schema notes but the description omits.

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 and front-loaded with a one-sentence purpose summary. It uses logical headers (COMMON USER ASKS, FIRST CHOICE FOR, WHEN TO USE, DON'T USE, EXAMPLES) and bullet points, with no redundant filler. Every section contributes to understanding and selection.

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

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

Given the tool's complexity (9 parameters, no output schema, no annotations), the description still provides substantial context: it states the output type, usage boundaries, and gives a worked example. It does not fully describe the response structure or all parameter interactions, but the schema covers parameters and the example covers the typical use case, making it sufficient for initial selection and invocation.

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 beyond the schema by providing a complete, realistic example ({"network":"base-mainnet","timeframe":"1h","limit":10}) that demonstrates how to combine the most important parameters for a common task, which aids correct invocation.

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 clear, specific verb and resource: 'Get the big picture for network-wide EVM activity with ranked contracts and compact overview metrics.' It distinguishes this tool from siblings by explicitly contrasting with 'raw record list' and 'chart buckets over time,' and includes a concrete example for 'Top contracts on Base.'

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' guidance, covering the decisive use cases (big picture, most active contracts, analytics-style overview) and the key exclusion (needing time buckets). However, it does not name specific alternative tools (e.g., portal_evm_query_transactions) as the rubric's top tier requires, though it implies them by describing what not to use.

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

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

No annotations are provided, so the description carries full disclosure burden. It accurately discloses that the tool returns an aggregate, contract-level summary rather than raw records, and it names the included output components (interactions, unique callers, optional events). However, it does not describe the exact response shape or execution behavior around mode/timeframe, leaving some minor ambiguity.

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 strong one-sentence summary and uses clearly labeled sections for quick scanning. It is somewhat longer than necessary—COMMON USER ASKS and FIRST CHOICE overlap—but every section still contributes useful guidance, so it remains appropriately structured.

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

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

For a tool with 7 parameters, no output schema, and no annotations, the description covers purpose, usage scenarios, exclusions, and a concrete example, while the schema fully documents all parameters. It could be more explicit about the response shape, but the listed output components and complete schema make selection and invocation sufficiently clear.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a concrete example with network, contract_address, and timeframe, but this does not substantially enrich the parameter meanings already provided in the schema. No parameter explanations are needed beyond what the schema gives.

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 ('Summarize') and identifies a precise resource: one specific contract's activity, including recent interactions, unique callers, and optional event activity. This clearly distinguishes it from sibling raw-log and transaction tools like portal_evm_query_logs 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 provides explicit WHEN TO USE and DON'T USE sections, including alternatives and exclusions. It states it is the FIRST CHOICE for contract-centric summaries and warns against using it when raw logs/transactions or general network activity are needed, which gives 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?

With no annotations provided, the description carries the full burden. It discloses that the tool performs a bounded-window search, accepts scan_order, and requires from_block or from_timestamp for older contracts. However, it does not state what happens when no deployment is found or whether it is strictly read-only. It adds useful context beyond the schema, so a 4 is appropriate.

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 clear sections (COMMON USER ASKS, WHEN TO USE, DON'T USE, EXAMPLES). It is front-loaded with a precise purpose statement. While some redundancy exists between 'COMMON USER ASKS' and 'FIRST CHOICE FOR', the organization makes it easy to scan, and every section contributes to tool 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?

Given the tool's complexity (11 parameters, no output schema), the description is remarkably complete. It covers the purpose, explicit usage conditions, exclusions, and provides three distinct examples illustrating different parameter combinations. It even explains the return value (create trace and parent transaction). This fully equips an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining parameter usage through examples, such as using aliases like 'bored apes', clarifying that from_block should be provided for older contracts, and explaining the purpose of search_depth_blocks. This exceeds the baseline.

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

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

The description opens with a specific verb+resource+scope: 'Locate the create trace and parent transaction that deployed a specific EVM contract address within a bounded window.' It clearly distinguishes this from general contract activity by stating 'You want a deployment lookup instead of general contract activity,' which sets it apart from sibling tools like portal_evm_get_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?

Explicit WHEN TO USE and DON'T USE sections provide clear conditions and exclusions. For example, 'DON'T USE: You need all activity for a contract after deployment' and 'you can provide a starting block/time window... or a supported well-known contract alias.' The examples also demonstrate concrete usage scenarios, giving the agent strong situational guidance.

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

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

No annotations are provided, so the description carries the full burden. It describes the expected output ('chart-ready EVM OHLC candles plus a recent trade tape') but does not disclose behavioral traits such as execution cost, return shape, pagination behavior, data availability caveats, or how the tool behaves when a source lacks factual trade amounts. The mode-related caveat lives in the schema, not in the tool description.

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: purpose, common asks, when/don't use, and examples. Each section earns its place; the examples are compact and immediately actionable. Front-loaded purpose sentence communicates the core behavior in one line.

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 of a 24-parameter multi-source tool with no output schema and no annotations, the description is quite complete: it covers supported sources, common use cases, exclusions, and example payloads. It does not describe the return envelope or pagination semantics, but the presence of standard OHLC candle concepts and the cursor parameter in the schema mitigate this gap.

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%, setting a baseline of 3. The description adds value above that by providing concrete JSON examples for each source type, mapping common user asks to parameter combinations (e.g., Uniswap v4 using pool_id, Aerodrome using pool_address and price_in). This helps disambiguate which parameters matter for which source.

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: 'Build chart-ready EVM OHLC candles plus a recent trade tape from supported DEX event sources'. It names exact protocols (Uniswap v2-style, v3/v4, Aerodrome Slipstream) and clearly distinguishes this from analytical or scalar metric tools by emphasizing candles and trade tape.

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 are explicit 'WHEN TO USE' and 'DON'T USE' sections providing clear positive and negative guidance. It stops short of naming alternative sibling tools (e.g., portal_evm_get_analytics or portal_get_time_series) for the excluded cases, so it lacks explicit alternative tool pointers.

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 for behavioral disclosure. It discloses performance tradeoffs ('RECOMMENDED: <10k blocks for fast (<1s) responses. Larger ranges may be slow or timeout') and output size reduction ('Use 'minimal' to reduce context usage'). It does not mention authentication or rate limits, but those are less critical for a read-only query tool, and the performance and output-size notes are valuable.

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 lengthy but well-structured with clear sections (COMMON USER ASKS, FIRST CHOICE FOR, WHEN TO USE, DON'T USE, EXAMPLES). Every section adds actionable value, and the core purpose is front-loaded. Some redundancy exists between 'COMMON USER ASKS' and 'FIRST CHOICE FOR', so it is not maximally concise, but it earns a high score for effective organization.

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 24 parameters and no output schema, the description covers the primary use cases with multiple request examples, performance warnings, and explicit alternative-tool guidance. It does not explain pagination via cursor or the exact response structure, but the schema covers parameter formats and field_preset hints at output content. This is a comprehensive description for a complex tool, leaving only minor gaps.

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

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

Schema coverage is 100%, which sets a baseline of 3. The description adds meaning beyond the schema by providing examples that demonstrate effective parameter combinations, such as 'use scan_order=latest, limit=1, and decode=true to expose decoded_log.decoded.token_id' and showing how to combine token_symbols, addresses, and event. It also clarifies that event aliases merge with topic0, which is not obvious from the 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 'Query raw EVM logs with address/topic filters, common event aliases, earliest/latest scanning, and optional inline decoding.' This clearly states a specific verb, resource, and key capabilities. It also distinguishes itself from the sibling token-transfer tool in the 'DON'T USE' section, satisfying the differentiation requirement.

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 dedicated 'WHEN TO USE' and 'DON'T USE' sections. It names the sibling token-transfer tool as the alternative when only token transfers are needed, and provides multiple concrete user scenarios in 'COMMON USER ASKS' and 'FIRST CHOICE FOR.' This is explicit guidance beyond just a general statement.

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 holds the burden. It discloses key behaviors: symbol resolution via 'open token-list data', bounded-window scanning, and scan_order semantics. It does not explicitly state there are no side effects, but the query verb and context make the read-only nature clear.

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 clear sections and front-loaded purpose. Each section earns its place; the examples are compact and useful. Slight verbosity prevents a perfect score.

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 15-parameter tool with no output schema and no annotations, the description is thorough: purpose, use cases, exclusions, and two examples. It doesn't mention pagination via cursor, but that is already in the schema. Overall it is highly complete for selection and invocation.

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 this is already well-documented. The description adds value with concrete examples showing parameter combinations (e.g., scan_order:'earliest' for first-transfer questions) and notes about merging token_symbols and token_addresses, 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+resource: 'Query token-transfer activity on EVM'. It clearly distinguishes from siblings by noting it avoids typing Transfer event signatures, setting it apart from portal_evm_query_logs 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?

Dedicated 'WHEN TO USE' and 'DON'T USE' sections provide explicit context. The 'DON'T USE' entry for arbitrary event logs implies the alternative tool (query_logs), giving clear when-not guidance.

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

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

No annotations are present, so the description carries the transparency burden. It adds useful context beyond the schema: evidence pivots, common method-name aliases, token-symbol resolution, and scan_order defaults ('transaction_type searches default to earliest'). It does not disclose rate limits, error behavior, or explicitly state read-only semantics, but as a query tool the non-mutating nature is clear from 'Query raw EVM transactions.' This is solid but not exhaustive.

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

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

The description is long but tightly organized with clear headers (COMMON USER ASKS, WHEN TO USE, DON'T USE, EXAMPLES). Every bullet serves a distinct purpose, and the examples are compact and illustrative. The opening sentence front-loads the core purpose. Given the tool's 35 parameters and investigative use cases, this length earns its place without redundancy.

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

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

This is a complex tool with 35 parameters and no output schema. The description covers a wide range of use cases, explicitly mentions optional logs/traces/state-diffs, and provides example inputs. However, it does not describe the output structure (e.g., what fields appear in a transaction record) beyond the schema's field_preset parameter, so the agent must infer response composition. Given the complexity, this is a minor gap in an otherwise comprehensive description.

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 parameter significance is mostly handled by the schema. The description adds value by showing realistic parameter combinations in EXAMPLES (e.g., transaction_type '0x1' with from_block and scan_order 'earliest') and explaining nuanced concepts like aggregate_by for 'top senders' and to_token_symbols for 'transfer calls to USDC.' This goes beyond simple param descriptions, helping an agent assemble correct invocations.

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: 'Query raw EVM transactions with optional logs, traces, state-diff context, and evidence pivots for transaction-level investigations.' This clearly distinguishes it from sibling tools like portal_evm_query_token_transfers or portal_evm_get_analytics by emphasizing 'raw' and 'transaction-level.' The DON'T USE section further reinforces its scope by excluding quick recent feeds and wallet-level summaries.

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 section provides seven concrete scenarios (e.g., 'need raw transaction records on an EVM network', 'find the first transaction matching a raw field condition'), and DON'T USE clearly says to avoid it for 'quick recent feed or wallet-level summary.' However, it does not name specific sibling alternatives like portal_get_recent_activity or portal_get_wallet_summary, instead referring generically to 'convenience tools,' so it stops short of an explicit alternative comparison.

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 burden of behavioral disclosure. It adds some context with 'indexed' and 'just' indicating a scope limitation, but it does not state whether the operation is read-only, what the return value looks like, or any error behavior. This is a moderate gap for a simple getter.

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 a one-sentence summary, clear sections (COMMON USER ASKS, WHEN TO USE, DON'T USE, EXAMPLES), and no redundant content. Each section earns its place and is front-loaded with the core purpose.

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

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

For a tool with only two parameters and no output schema, the description is highly complete. It covers the purpose, common use cases, exclusions, and example invocations. The only missing piece is return format, but that is likely self-evident for a 'get head' operation and not critical here.

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?

Although schema coverage is 100%, the description adds value through concrete examples mapping 'latest' and 'finalized' to the type parameter and showing network aliases. This clarifies usage 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 clearly states 'Get just the latest indexed head block or slot for a network', providing a specific verb and resource. It distinguishes from siblings by positioning itself as the first choice for head retrieval and explicitly excluding network status or activity 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 includes explicit WHEN TO USE and DON'T USE sections, listing concrete use cases and exclusions. It also labels itself as FIRST CHOICE FOR, giving clear guidance on when this tool should be selected over alternatives.

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

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

No annotations are provided, so the description carries the full burden. It reveals the output topics (freshness, lag, heads, tables) and implies a read-only info query, but it does not explicitly state that no state is modified or describe data source specifics. For a simple info tool this is acceptable but lacks explicit side-effect disclosure.

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

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

The description is well-structured with labeled sections and front-loads the core purpose. It is somewhat verbose with repeated guidance, but each section adds distinct value, so no content is wasted.

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

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

With one parameter, no annotations, and no output schema, the description provides all necessary context: what it does, when to use, when not to use, and an example. It fully equips an agent to select and invoke the tool correctly.

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

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

Schema coverage for the single parameter is 100%, so the baseline is 3. The description adds a concrete example ('base-mainnet') showing the expected value format, which goes beyond the schema's generic 'Network name or alias' and helps invocation.

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 directly states the tool answers 'is this network caught up?' with indexing freshness, lag, heads, and available tables. It clearly distinguishes from sibling tools by focusing on network info rather than block, transaction, or analytics 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?

Provides explicit 'FIRST CHOICE FOR', 'WHEN TO USE', and 'DON'T USE' sections. It directs users to avoid this tool when only needing the latest block/slot, implicitly pointing to alternatives like portal_get_head. This gives clear decision support.

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

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

With no annotations provided, the description carries the burden. It discloses useful behavioral traits: 'chronological paging' and 'investigation pivots', and describes the feed as 'bounded' and 'recent evidence timeline', implying a read-only, safe operation. It could be more explicit about the return shape or authentication needs, but the guidance provided goes beyond 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?

The description is longer than two sentences but well-structured with clear section headings (COMMON USER ASKS, FIRST CHOICE FOR, WHEN TO USE, DON'T USE, EXAMPLES). Each sentence contributes to usability, and the examples are compact. The structure aids scanning without being 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 the tool's complexity (8 parameters, no output schema, many siblings), the description is remarkably complete. It covers purpose, usage context, exclusions, and concrete examples. It does not explain return values, but with no output schema and a feed-like tool, the provided context is sufficient for an agent to select and invoke the tool correctly.

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

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

Although schema description coverage is 100%, the description adds concrete examples that disambiguate parameter usage, such as network short names ('base-mainnet') and timeframe formats ('1h', '100'). This clarifies how to combine network, timeframe, and limit in practice, which is value beyond the schema's individual field 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 a simple recent-activity feed across EVM, Solana, Bitcoin, or Hyperliquid'. It clearly distinguishes itself from sibling raw query tools by emphasizing 'simple' and 'recent-activity feed' rather than raw logs or chain-specific fields. The 'FIRST CHOICE FOR' section further reinforces its unique role as a starting point for incident triage.

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, listing concrete scenarios like 'You want a quick recent-activity feed' and exclusions like 'You need raw logs, instructions, or chain-specific fields'. It also names alternatives implicitly by referring to 'raw VM-specific query tools', giving an agent clear decision boundaries.

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. It explains behavioral traits such as the default 6h interactive window, longer windows taking longer, and returning 'chart-ready metric buckets.' However, it does not explicitly state that it is read-only or describe the exact return structure, which would be useful given the lack of an output 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?

The description is well-structured with clear sections (purpose, common user asks, first choice, when to use, don't use, examples). Every sentence contributes useful information, and the examples are concise. It maintains high information density without fluff.

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

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

Given the tool has 11 parameters, no output schema, and no annotations, the description is relatively complete: it covers purpose, usage guidance, examples, and limitations. However, it only vaguely refers to 'chart-ready metric buckets' without specifying the output format or fields, which is a gap for agents expecting structured results. More explicit return-value documentation would push this to 5.

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 covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds value beyond the schema by providing concrete JSON examples for 'Base transactions per 15m bucket' and 'Compare two periods,' demonstrating how parameters like network, metric, duration, interval, and compare_previous combine. It also clarifies the default duration and interval behavior.

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

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

The description clearly states the tool builds 'simple activity charts and other time-series views across supported VMs,' which is a specific verb+resource. It differentiates from siblings by explicitly mentioning 'compare-previous windows' and 'grouped EVM contract trends,' and the 'DON'T USE' section contrasts with OHLC and raw record 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 guidance with 'FIRST CHOICE FOR,' 'WHEN TO USE,' and 'DON'T USE' sections. It names alternatives like 'raw record lists' and 'DEX pool candles or OHLC output,' and gives examples for common scenarios, making it clear when to select this tool over 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly conveys that this is a summarization (read-oriented) operation, returns 'inbound/outbound flow, top counterparties, largest movements, and exact next pivots', and implies non-raw output. However, it does not explicitly state that it is non-destructive or mention potential rate limits/pagination caveats, though the nature of 'summarize' and evidence pivots sufficiently indicates safe read 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 well-structured with clear headings (COMMON USER ASKS, FIRST CHOICE FOR, WHEN TO USE, DON'T USE, EXAMPLES) and front-loaded with a concise summary sentence. There is slight redundancy between 'FIRST CHOICE FOR' and 'WHEN TO USE' (both mention suspicious wallet triage), and the overall length is justified but could be slightly tightened without losing value.

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

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

Despite lacking an output schema and annotations, the description provides enough context: it explains the tool's role in the ecosystem (summary vs raw records), expected output components (overview, movements, counterparties, pivots), and includes concrete examples for two networks. It does not enumerate all supported networks or explain cursor-based pagination, but those are adequately covered by the schema, and the description compensates well for the missing output schema by describing the high-level return content.

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 does not add per-parameter semantics beyond the schema, but the examples ('EVM wallet fund-flow triage: {"network":"base-mainnet","address":"0xabc...","timeframe":"24h"}') reinforce how network, address, and timeframe map to real use. This is marginal added value, keeping the score at baseline.

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

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

The description uses a specific verb 'summarize' with a precise resource ('wallet activity and fund flow') and details the output components: 'shared overview, asset movement, counterparties, evidence pivots, and follow-up filters'. It clearly distinguishes from sibling raw-query tools by stating it is the 'FIRST CHOICE FOR one-call wallet analysis' and 'before drilling into raw records', and the DON'T USE section explicitly excludes raw record retrieval.

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 guidance with WHEN TO USE conditions ('You want a single high-level answer...', 'You want inbound/outbound flow...', 'The user asks to investigate a suspicious wallet...') and a DON'T USE condition ('You need every raw record with full chain-specific fields and no summarization'). It also names the alternative category (raw transactions/fills) by contrast, satisfying the when-not/alternatives criterion.

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 behavioral disclosure burden. It communicates that this is a read-only aggregated analytics operation ('grouped aggregate sections', 'big-picture') and describes the scope. However, it does not mention execution cost, pagination behavior beyond what's in schema, or how the 'mode' parameter affects runtime behavior. The description adds some behavioral context but not complete coverage.

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 organized into clear sections (summary, asks, when/don't use, examples) with each earning its place. It is thorough without being bloated.

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 9 optional parameters and no output schema, the description provides strong context for purpose, use cases, and exclusions, plus representative examples. It lacks some detail on the exact shape of the response and the meaning of mode/response_format, but the schema covers the parameters. Given the complexity, this is adequately complete.

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

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

Schema coverage is 100%, so baseline is 3. The examples include concrete values for network and timeframe, illustrating common usage. However, the description does not explain parameters like mode, cursor, response_format, or timestamp formats beyond the schema's own descriptions.

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

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

The description opens with a specific verb and resource: 'Get the big-picture Hyperliquid fill analytics' and enumerates concrete output dimensions (top traders, volume by coin, fees, PnL). It clearly differentiates from sibling tools like portal_hyperliquid_query_fills and portal_hyperliquid_get_ohlc through the DON'T USE section.

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 provide explicit guidance, including when not to use (individual fills or OHLC candles), which implicitly directs to siblings. COMMON USER ASKS helps with typical intent.

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 reveals the tool aggregates fills into fixed buckets, uses auto intervals with explicit mapping (1h→5m, etc.), and returns OHLC, volume, and VWAP. This is meaningful behavioral context beyond the tool name.

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 (purpose, when/don't, example). It is front-loaded with the primary purpose and each section earns its place. The example is concise and illustrative.

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 6 parameters, no output schema, and no annotations. The description covers the data source (fills), output components (OHLC, volume, VWAP), and provides a concrete example. It doesn't explain pagination or return structure in detail, but the schema covers parameters and the example compensates.

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?

All 6 parameters are already described in the schema with examples and defaults (100% coverage). The description adds only an example JSON, which is helpful but not additional semantic meaning for parameters. Per baseline, score 3.

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

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

The description opens with a specific verb-resource pair: 'Build chart-ready Hyperliquid trade OHLC candles with fixed buckets and auto intervals.' It clearly distinguishes from siblings by noting 'DON'T USE: scalar time-series buckets or raw fills', which differentiates it from portal_get_time_series and portal_hyperliquid_query_fills.

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' and 'DON'T USE' sections. When: 'you want candles for one coin on Hyperliquid' and 'need chart-ready OHLC, volume, and VWAP data from fills.' Don't: 'scalar time-series buckets or raw fills.' This gives clear selection guidance, though it doesn't name alternative tool names.

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 for behavioral disclosure. It correctly labels the tool as a query, mentions the raw granularity, and notes the filter dimensions, but it does not mention pagination (cursor), response format defaults, or any read-only/safety implications. This is adequate but not rich.

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

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

The description is well-structured with a clear summary, user ask examples, explicit when/don't-use guidance, and a concrete example. Each section serves a distinct purpose without fluff, and the most important information is front-loaded.

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

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

Given the tool's 18 parameters and lack of output schema, the description effectively covers what the tool does, when to use it, and provides a usage example. It does not describe return value shape or pagination behavior, but the schema covers parameter details, and the example demonstrates a realistic call. This is nearly complete for a query tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description paraphrases the key filters (trader, coin, direction, builder, fee token) and provides a realistic example with coin and timeframe, which adds a small amount of interpretive value over the raw schema descriptions. However, it does not explain any parameter mechanics beyond what the schema already provides.

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

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

The description opens with a specific verb and resource: 'Query raw individual Hyperliquid fills' with explicit context fields (trader, coin, fee, PnL, builder). It clearly distinguishes from siblings by stating this is for raw fills, not aggregates or candles, and the DON'T USE section reinforces the distinction.

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 provide explicit guidance on when to invoke this tool and when to avoid it in favor of aggregate/big-picture tools. It names alternatives conceptually (top traders, grouped aggregates, candles) and gives a concrete example, making the decision clear.

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

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

With no annotations, the description carries the transparency burden. It adds context that this tool is a metadata/discovery operation (not live data), supports real-time availability filtering, and serves as a prerequisite lookup step. However, it does not explicitly state the return format or describe the 'real-time indexed head' concept beyond the parameter name, leaving a small 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?

The description is well-structured into sections (common asks, first choice, when to use, don't use, examples). Every section serves a distinct purpose and adds value; there is no fluff. The opening sentence is a clear front-loaded purpose. Given the tool's complexity (5 parameters, multiple VM families), this length is appropriate and each sentence earns its place.

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

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

The description covers usage scenarios and parameter examples thoroughly, but with no output schema, it does not describe what the returned network list contains or how results are structured. For a simple list/discovery tool, this is a moderate gap; the name implies a list, but exact return fields are left unspecified. Thus, it is minimally complete but not fully explanatory.

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's examples ('Find Base-like networks: {"query":"base","limit":10}') illustrate parameter combinations but add little semantic meaning beyond what the schema already provides for each parameter. It does not clarify value formats or edge cases, so it does not push above baseline.

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

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

The description opens with a specific verb+resource: 'Find the right network or chain name to use across EVM, Solana, Bitcoin, Substrate, and Hyperliquid.' This clearly distinguishes the tool from its data-query siblings, which focus on live chain data rather than network discovery. The purpose is unambiguous and well-scoped.

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 when-not-to-use guidance, including a 'FIRST CHOICE' section and a 'DON'T USE' section: 'You already know the exact network and want live data from that network.' It also lists specific filter use cases (VM family, network type, real-time availability), giving clear criteria for invocation. This exceeds baseline guidance by naming exclusions.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: ambiguity is "kept explicit", it returns deterministic filters, and it provides source-backed addresses. However, it does not describe the return format, pagination behavior, or error/ambiguity handling in detail, but the examples and mention of 'limit' hint at multiple matches.

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 section headers, front-loaded with the core purpose. Every section earns its place: common asks, usage criteria, exclusions, and examples. It is appropriately sized for the tool's complexity and easy to scan.

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

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

Given there is no output schema, the description should explain what the tool returns. It does mention "query-ready identifiers", "token contract addresses", and "EVM filters", but does not fully specify the response structure or edge cases. However, the examples and extensive usage guidance make it largely complete for an agent to correctly select and invoke the tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant value by providing concrete example payloads for common asks (e.g., USDC on Base) and explaining how to combine `kind`, `network`, and `query`. This goes beyond the schema's individual parameter descriptions and clarifies usage patterns.

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: "Resolve user-facing blockchain entities into query-ready identifiers". It clearly distinguishes the tool from sibling query/analytics tools by focusing on resolution, and explicitly lists "FIRST CHOICE FOR" scenarios that separate it from 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?

The description has dedicated "WHEN TO USE" and "DON'T USE" sections with explicit conditions and examples. It tells the agent exactly when to use this tool (e.g., user names a token symbol) and when not to (if exact address/filter already known), providing clear decision guidance.

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

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

With no annotations, the description carries the transparency burden. It implies a read-only analytics operation via 'Get' and 'analytics' and clarifies it does not return raw records, but it does not explicitly state side-effect-free behavior, pagination behavior, or performance/rate-limit considerations.

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 a front-loaded summary and clear labeled sections (COMMON USER ASKS, FIRST CHOICE, WHEN TO USE, DON'T USE, EXAMPLES). It repeats 'big picture for Solana right now' a few times but remains appropriately concise 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?

For a 10-parameter analytics tool with no output schema and no annotations, the description provides strong selection context: purpose, when to use, when not to use, and illustrative examples. It does not describe the output structure or advanced parameter interactions, but the schema covers parameter details and examples cover common flows.

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 example payloads showing common uses of network, timeframe, and include_programs, but it does not add meaningful semantics beyond what parameter descriptions already provide for cursor, mode, or timestamps.

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 distinguishes from sibling raw-record tools through the DON'T USE section, which excludes raw transaction/instruction 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?

Explicit WHEN TO USE and DON'T USE sections provide concrete use cases (network health snapshot, throughput/fee analytics) and exclusions (chart buckets, raw records). However, no specific alternative sibling tool is named, falling just short of the highest guidance standard.

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 clarify that the tool returns 'raw' instructions (not decoded) and implies read-only behavior, but it omits details about pagination (cursor), output structure, or performance characteristics. The example hints at usage but doesn't disclose rate limits or response shape, leaving gaps.

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

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

The description is compact and well-structured with clear headings (COMMON USER ASKS, WHEN TO USE, DON'T USE, EXAMPLES). Every section serves a purpose, and the example is concise. No redundancy or filler; it front-loads the core purpose immediately.

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 39 parameters and no output schema, the description covers the essential context: what the tool does, when to use it, and how to frame a common query via example. It doesn't mention return format or pagination, but given the rich schema and focused use cases, it is close to fully adequate for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by providing a full example with program_id (as an array), network, timeframe, and limit, showing how to compose filters. This concrete illustration helps agents understand parameter usage more effectively than the raw 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 'Query raw Solana instructions with program and account filters,' a specific verb+resource statement that clearly distinguishes this tool from siblings like portal_solana_query_transactions (transaction-level). It also names concrete use cases (Token Program, Jupiter, System Program, Anchor discriminators), reinforcing its distinctive scope.

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

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

Explicit 'WHEN TO USE' and 'DON'T USE' sections provide clear context: use for program-level or account-level instruction activity, avoid for transaction-level queries. A concrete example for Token Program instructions further demonstrates when and how to invoke the tool, leaving little ambiguity about appropriate use.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose pagination behavior, default response format, network fallback, or performance implications of include flags. It only repeats the existence of options without behavioral detail.

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 organized with clear sections and examples, making it easy to scan. However, the inclusion of the invalid 'program_id' example and some redundancy (e.g., repeating 'raw') slightly detract from an otherwise crisp 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?

The tool has 17 parameters and no output schema, yet the description does not cover cursor pagination, network requirements, or output shape. The two examples only address simple cases, leaving many common tasks (e.g., using timestamps, filters, response formats) undocumented.

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?

While schema coverage is complete (100%), the description adds an example using 'program_id' which is not present in the input schema, misleading the agent. It also fails to explain parameter interactions (e.g., from_block vs timeframe, response_format defaults) 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 clearly states it queries raw Solana transactions with optional context (balances, rewards, logs, instructions). The verb 'Query' is specific and the resource is well-defined. It differentiates from sibling tools like portal_solana_query_instructions and portal_solana_get_analytics.

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, along with common user asks. It clearly states when to choose this tool over convenience tools and when to avoid it, making selection straightforward.

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

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

No annotations are provided, so the description must fully disclose behavior. It mentions the 'indexed window' scope, indicating the tool returns aggregated snapshots over already-indexed data rather than live raw records. It also notes that the default is 'complete requested-window analysis' via the schema's mode field, but the description itself does not elaborate on potential limitations or error scenarios, keeping it from a top score.

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

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

The description is well-structured with headers and a clear front-loaded first sentence, but it suffers from redundancy—phrases like 'Polkadot activity analytics in an indexed window' and 'how is Polkadot doing' appear multiple times across 'COMMON USER ASKS', 'FIRST CHOICE FOR', and 'WHEN TO USE.' It could be trimmed significantly without losing message 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 9 parameters, no annotations, and no output schema, the description does a solid job outlining the tool's purpose and expected outputs ('event, call, and extrinsic counts plus top event and call names'). It also clarifies the indexed-window constraint and provides usage examples. However, it does not describe edge cases or exact response structure, which is a minor gap.

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

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

The input schema covers all 9 parameters with individual descriptions (100% coverage), so the baseline is 3. The description adds example payloads (e.g., {"network":"polkadot","timeframe":"1h"}) and contextual hints like 'top event and call names' matching section_limit, but it does not introduce new parameter meanings beyond what the schema already provides.

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

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

The description opens with 'Analytics snapshot for Substrate or Polkadot activity in an indexed window, with event, call, and extrinsic counts plus top event and call names,' which is a specific verb+resource+scope statement. It clearly differentiates from raw query siblings like portal_substrate_query_events and portal_substrate_query_calls by emphasizing aggregated counts and top names.

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, stating when to use the tool (e.g., 'quick Substrate network snapshot or health check') and when to avoid it ('You need full raw event or call records'). This provides direct decision guidance relative to the sibling query 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. It discloses that the tool returns raw call rows and optionally attaches events, subcalls, stack, or extrinsic context. However, it does not mention pagination behavior (cursor, limit default) or the default response format, which are relevant behavioral traits for an agent using the 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 structured with clear headers (COMMON USER ASKS, FIRST CHOICE FOR, WHEN TO USE, DON'T USE, EXAMPLES). The opening sentence is a concise summary, and each section delivers actionable info without fluff. Examples are compact and illustrate parameter usage efficiently.

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 15 parameters and no output schema or annotations, the description covers primary use cases, distinguishes from sibling tools, and provides two concrete examples. It does not fully specify return shape or pagination, but given the schema covers limit/cursor/response_format, the description is sufficiently complete for practical selection.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value with examples showing how to combine parameters (e.g., network, timeframe, call_names, include_events, limit) and introduces the concept of 'pallet/call-name filters' that maps to the call_names parameter. This goes beyond the schema's individual parameter 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 first sentence states a specific verb+resource: 'Query raw Substrate or Polkadot calls with pallet/call-name filters and optional child-call, emitted-event, or extrinsic context.' This clearly distinguishes it from siblings like portal_substrate_query_events (events) and portal_solana_query_instructions (different network) by focusing on raw call rows.

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, with concrete criteria like 'You need raw call records' vs. 'You want events or aggregate analytics rather than call rows.' It also provides common user asks and examples, giving clear direction on when this tool is appropriate compared to alternatives.

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

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

No annotations are provided, so the description must carry the behavioral transparency burden. It communicates the tool returns raw event rows, supports optional parent call/extrinsic context, and uses a compact-by-default response format (via schema). However, it does not explicitly state read-only behavior, pagination, rate limits, or data freshness expectations, which would be useful given zero annotation coverage. The example helps show behavior in practice.

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 headings and bullet points. The opening sentence is front-loaded with the core purpose. The COMMON USER ASKS, WHEN TO USE, DON'T USE, and EXAMPLES sections are concise and each sentence earns its place. It avoids redundancy and unnecessary 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?

Given the tool's complexity (14 parameters, no required fields, no output schema, no annotations), the description provides strong usage context and a representative example. However, it doesn't describe the shape of event row results or clarify what 'raw' means in terms of decoded data, which would improve completeness. Still, the example and usage guidance are strong enough for reliable tool selection.

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

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

Schema description coverage is 100%, so parameters are already well-documented. The description adds value with a concrete example showing parameter combination (network, timeframe, event_names, limit) and a common user ask using event_names format (Balances.Transfer). This clarifies how qualified event names work and how to structure a query, going beyond individual schema descriptions.

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

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

The description clearly states 'Query raw Substrate or Polkadot event rows with pallet/event-name filters and optional parent call or extrinsic context.' This is a specific verb+resource with scope. It also distinguishes itself from siblings by noting it's the 'FIRST CHOICE FOR raw event rows' and explicitly says 'DON'T USE' for calls or aggregate analytics, differentiating from portal_substrate_query_calls and portal_substrate_get_analytics.

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' section provides three explicit scenarios (raw event records, pallet-level event activity, event rows first). The 'DON'T USE' section explicitly excludes calls and aggregate analytics, giving clear when-not-to-use guidance. The 'FIRST CHOICE FOR' section further reinforces the intended use case.

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