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 full burden. It mentions that include_address_activity requires extra queries (slower), but does not disclose other behaviors like parameter conflict resolution, rate limits, or side effects. A bit more detail is needed.

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

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

The description is well-structured with sections and examples, but slightly verbose. It is front-loaded with the main purpose. Every sentence adds value, but some redundancy exists.

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 9 parameters and no output schema. The description does not detail the return structure or explain parameter conflicts (e.g., from_block vs timeframe). More guidance is needed for complete usage.

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

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

Schema coverage is 100%, so the schema already describes parameters. The description adds value by explaining the 'mode' parameter (fast vs deep) and providing block counts for timeframe. This exceeds the baseline of 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 clearly states it gets a 'big picture' for Bitcoin block, fee, and address activity. It specifies the resource (Bitcoin analytics) and verb (get), and distinguishes from sibling tools by focusing on network-level analytics rather than raw transactions.

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

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

The description includes dedicated sections like 'COMMON USER ASKS', 'FIRST CHOICE FOR', 'WHEN TO USE', and 'DON'T USE'. It explicitly advises against using when needing raw transactions and provides an example, making usage conditions very clear.

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

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

No annotations are provided, so the description should disclose behavioral traits. It does not mention whether the tool is read-only, destructive, requires authentication, or has rate limits. The description focuses on usage rather than side effects or behavior beyond what the input schema states.

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 sections (COMMON USER ASKS, WHEN TO USE, etc.) and front-loads the main purpose. However, it is somewhat verbose, repeating parameter information present in the schema, which could be more concise.

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

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

Given the complexity of 12 parameters and no output schema, the description covers major use cases and provides examples. It lacks details on return values or error handling, but the examples and usage guidelines make it reasonably complete for an agent.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds minimal semantic value beyond the schema; examples illustrate parameter combinations but do not explain relationships (e.g., timeframe vs. from_block/to_block) or cursor usage in depth.

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

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

The description explicitly states 'Query raw Bitcoin transactions and optionally attach inputs and outputs inline,' providing a specific verb and resource. It distinguishes from sibling tools (e.g., EVM, Solana, analytics tools) by focusing on raw Bitcoin transactions with optional inline attachments.

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, clearly specifying scenarios (e.g., needing raw records, UTXO envelope) and exclusions (e.g., quick wallet summary). Examples illustrate common use cases, providing practical 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 full burden. It does not explicitly state that the tool is read-only, idempotent, or whether any side effects occur. The 'Query' verb implies read-only but lacks explicit 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 (ADVANCED, COMMON USER ASKS, WHEN TO USE, DON'T USE, EXAMPLES). It is concise, front-loaded, and every sentence adds value.

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

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

Given the 13 parameters and no output schema, the description covers the tool's purpose, usage context, and provides an example. It lacks output format details but is otherwise complete for its domain.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds an example (network, timeframe, limit) but does not elaborate on parameter meaning beyond the schema. Minimal added value.

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 Hyperliquid replica-command actions (orders, cancels, leverage updates) and distinguishes it from fills and analytics. The 'COMMON USER ASKS' section reinforces the 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?

Explicit 'WHEN TO USE' and 'DON'T USE' sections provide clear guidance on when to use this tool (debugging replica-command records, needing raw order events) and when not to (public trading, fills, analytics).

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

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

No annotations exist, so description bears full burden. It states it queries raw block records but does not disclose read-only nature, side effects, or response format. While schema explains parameters, behavioral traits like 'read-only' are missing. Adequate but not comprehensive.

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

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

Extremely concise yet structured with clear sections (ADVANCED, COMMON USER ASKS, WHEN/DON'T USE, EXAMPLES). Every sentence adds value, no redundancy, and 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?

Given 11 parameters and no output schema, the description sufficiently covers purpose and usage scenarios. It provides an example and distinguishes from siblings. Lacks details on return format, but for a query tool with rich schema, this is acceptable. Slightly incomplete for agents that need output structure.

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

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

Schema description coverage is 100% with detailed parameter descriptions. The description adds minimal extra value beyond an example usage. Baseline 3 is appropriate as schema handles most semantics; the example provides practical context but no deep parameter clarification.

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

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

The description clearly states 'Query raw block records directly for EVM, Solana, or Bitcoin' and specifies it's for debugging Portal coverage or block-level fields. This distinctively separates it from sibling tools like transactions 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?

Explicit WHEN TO USE and DON'T USE sections provide clear context: use for debugging raw blocks, not for normal end-user questions, and prefer other tools like recent activity or raw transactions first. Example usage reinforces guidelines.

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

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

No annotations provided, so description must disclose behavioral traits. It mentions 'debugging' and 'inspect exact versus estimated resolution', implying a read-only operation, but lacks details on potential costs, rate limits, or other side effects. The 'ADVANCED' label hints at caution, but more explicit disclosure would improve transparency.

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

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

The description is well-organized into clear sections (header, common asks, when/don't use, examples). Each sentence is purposeful, and the entire description is concise without unnecessary words.

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

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

Given the tool's simplicity (2 parameters, no output schema), the description covers purpose, usage context, and examples. It could be more explicit about the return value format, but the phrase 'nearest indexed block or slot' gives a reasonable expectation. Overall, it is sufficiently complete for most contexts.

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% for both parameters, but description adds value by providing concrete examples (e.g., '1h ago', ISO datetime) and demonstrating usage with network names like 'base-mainnet' and 'polkadot'. This clarifies acceptable input formats beyond the schema's generic descriptions.

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

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

Description clearly states 'Resolve a timestamp to the nearest indexed block or slot', providing a specific verb and resource. It distinguishes from sibling tools like portal_get_time_series and portal_get_head by labeling itself as 'ADVANCED' and focusing on debugging timestamp windows.

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 explicitly states debugging scenarios (timestamp windows, manual block-range queries), and the DON'T USE section warns against using it when other tools ('most public tools') accept natural timestamps directly, offering clear guidance on 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 full burden for behavioral transparency. It does not disclose whether the tool is read-only, destructive, or any side effects. It mentions 'compact overview metrics' but doesn't explain what that entails or if there are rate limits/auth needs. The description lacks essential safety and behavior context.

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

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

The description is highly concise and well-structured: header, common asks, first choice, when to use, don't use, and an example. Every sentence serves a purpose, and the information is front-loaded. No redundancy.

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

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

Given that there is no output schema, the description could better explain what the response contains beyond 'ranked contracts and compact overview metrics'. With 9 parameters and many sibling tools, the description is adequate but not fully complete; it doesn't outline the return structure or how to handle pagination.

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 marginal value beyond the schema: it provides an example usage and explains the concept of 'ranked contracts'. However, it doesn't add syntax or format details for parameters like 'from_timestamp' or 'mode' 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 clearly states 'Get the big picture for network-wide EVM activity with ranked contracts and compact overview metrics.' It specifies the verb, resource, and output. It also distinguishes itself from raw record lists and mentions 'FIRST CHOICE FOR: the big picture' which helps differentiate from sibling tools.

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

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

The description provides explicit 'WHEN TO USE' and 'DON'T USE' sections, with specific scenarios like wanting the most active contracts. It gives a clear example. However, it doesn't explicitly name alternative sibling tools (e.g., portal_evm_get_contract_activity) for when to use those instead, leaving some ambiguity.

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

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

No annotations are provided, so the description must cover behavioral traits. It explains the output (interactions, callers, events) and parameter details, but lacks information on data freshness, rate limits, or side effects. It is adequate but not thorough.

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

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

The description is concise and well-structured with clear sections (FIRST CHOICE, WHEN TO USE, DON'T USE, EXAMPLES). Every sentence adds value without redundancy.

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

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

Given the 7 parameters (all described in schema) and no output schema, the description covers the essential output (interactions, callers, events) and includes an example. It is complete enough for agent use, though a detailed output format would elevate it.

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

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

Schema coverage is 100%, so the schema already documents each parameter fully. The description adds minimal extra context beyond the schema descriptions (e.g., examples for time formats). Baseline 3 is appropriate.

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

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

The description clearly states the purpose: 'Summarize what one specific contract has been doing lately...' with a specific verb and resource. It distinguishes from sibling tools that deal with raw logs or other networks, making it easy for an agent to select correctly.

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

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

The description explicitly provides 'WHEN TO USE' and 'DON'T USE' sections, including example user asks and clear exclusions. It tells the agent when to choose this tool over alternatives like raw logs.

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 effectively communicates the tool's behavior: it locates deployment traces within a bounded window, supports scanning order, and requires block/time hints for older contracts. No contradictions.

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 sections and examples, making it easy to parse. It is somewhat verbose but every part adds useful information.

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

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

The tool has 11 parameters and no output schema, yet the description fully explains the tool's function, usage conditions, and provides multiple examples. It is complete and leaves no ambiguity.

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

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

Input schema has 100% coverage, so parameters are documented. The description adds value by providing context, usage hints (e.g., 'from_block: Provide this for older contracts'), and examples that clarify parameter combinations.

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

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

The description clearly states the tool's purpose: 'Locate the create trace and parent transaction that deployed a specific EVM contract address within a bounded window.' This is specific and distinct 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?

The description includes explicit sections for 'WHEN TO USE', 'DON'T USE', and examples. It tells the agent when to use this tool and when to consider alternatives, e.g., not for general contract activity.

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

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

No annotations provided, so description carries full burden. It discloses that v4 uses PoolManager Swap events not per-pool addresses, explains execution depth modes (fast/deep), and gives example parameters. However, it does not mention data freshness, rate limits, or idempotency, leaving minor gaps for a complex 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?

Well-structured with clear sections (common asks, when/don't use, examples). Front-loaded with core purpose. However, length is high due to many examples and parameter repetition, which could be slightly condensed without losing clarity.

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 many parameters and no output schema, the description provides extensive examples and parameter details. However, it lacks explanation of the output format (OHLC candle structure, trade tape fields) and details on 'deep' vs 'fast' mode behavior. A more complete description would cover return schema or common response fields.

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%, but the description adds value beyond schema by providing usage context (e.g., 'price_in: auto picks the more human-readable quote side') and multiple examples that map parameters to real-world scenarios.

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 'chart-ready EVM OHLC candles plus a recent trade tape from supported DEX event sources'. It lists common user asks and provides examples, effectively distinguishing it from sibling tools like portal_evm_get_analytics or portal_get_time_series.

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

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

Explicit 'WHEN TO USE' and 'DON'T USE' sections with clear alternatives (e.g., 'You need OHLC candles for supported EVM event-derived price sources' vs 'You only need counts or scalar metrics over time'). Also provides examples mapping to specific use cases.

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

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

No annotations provided, so description carries full burden. It discloses performance implications (recommended block range) and parameter effects (addresses/topics for speed). Does not mention auth or rate limits, but adequate for a read operation.

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

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

Well-structured with clear headers (COMMON USER ASKS, WHEN TO USE, DON'T USE, EXAMPLES). Front-loaded summary sentence. No wasted text; every section adds value.

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

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

Highly comprehensive given 24 parameters and no output schema. Covers use cases, parameter explanations, examples, performance tips. Examples show expected outputs like decoded_log.token_id.

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%, baseline 3. Description adds meaning beyond schema: explains event aliases, topic roles, scan_order usage, token_symbols resolution, examples. Significant extra context.

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 EVM logs with filters, aliases, scanning, and decoding. It specifies the tool's resource and action, and distinguishes from sibling tools like token-transfer tool.

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 list and DON'T USE section with alternative tool mention (token-transfer). Includes specific scenarios like first/last event and NFT mint lookups.

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 description carries full burden. It discloses that the tool is the 'fastest answer' and 'easiest trivial query', implying read-only and efficient behavior. However, it does not explicitly mention side effects, authentication needs, or rate limits, which would be helpful.

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

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

Description is well-structured with clear sections and front-loaded purpose. Every sentence adds value; examples are concise and illustrative. No redundant or wasteful text.

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 lack of output schema, description could be more explicit about the response format (e.g., what fields are returned). However, tool name implies standard transfer event data, and the parameter documentation covers inputs well. Missing info on pagination behavior is minor given cursor parameter.

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

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

Schema description coverage is 100% (all parameters described). Description adds additional meaning beyond schema with common user asks and examples that illustrate parameter usage (e.g., 'scan_order' for earliest first). It provides context for parameter choices like token_symbols vs token_addresses.

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 tool name and description clearly state it queries token-transfer activity on EVM. It uses specific verbs ('query', 'get') and resource ('token transfers'), and distinguishes from sibling tools like portal_evm_query_logs by noting it avoids needing to remember Transfer event signatures.

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

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

Description includes explicit 'WHEN TO USE' and 'DON'T USE' sections, providing clear context for appropriate usage and exclusions. It gives common user asks and examples, guiding the agent in selecting this tool 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 of behavioral disclosure. It explains that the tool can include logs, traces, state diffs, and mentions scanning order, safety caps (via param description), and block range recommendations. While it implicitly indicates read-only behavior through the word 'query', it does not explicitly state safety or error handling. Still, the provided details give sufficient behavioral insight for an agent.

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 (COMMON USER ASKS, WHEN TO USE, DON'T USE, EXAMPLES) and front-loaded with the core purpose. However, it is lengthy due to the complexity of the tool. While every sentence adds value, some sections repeat concepts (e.g., COMMON USER ASKS overlaps with WHEN TO USE), preventing 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?

Given the tool's 35 parameters and no output schema, the description provides substantial guidance on when and how to use the tool, with multiple examples. However, it does not describe the structure of the response or the format of returned transaction data, which is a gap for an agent to fully understand the output. The description is adequate but not fully complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add per-parameter semantics beyond what the schema already provides. It includes examples that illustrate usage of parameters, but the schema descriptions themselves are already detailed. Thus, the description meets the baseline without adding significant extra parameter meaning.

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 begins with a clear and specific verb-resource statement: 'Query raw EVM transactions with optional logs, traces, state-diff context, and evidence pivots for transaction-level investigations.' It lists common user asks and explicitly distinguishes from convenience tools, making the tool's purpose unambiguous and differentiating it from siblings like portal_evm_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?

Contains dedicated 'WHEN TO USE' and 'DON'T USE' sections with explicit scenarios and alternatives. For example, it advises against using this tool for 'only a quick recent feed or wallet-level summary' and provides specific use cases like filtering by sender or finding first EIP-2930 transaction. This gives clear context for when to invoke this tool vs. other methods.

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

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

No annotations provided, so the description bears the burden. It discloses the tool is for getting the current head and gives examples. However, it does not explicitly state if it's read-only, what exactly is returned (e.g., just a number or more), or any potential side effects. Lacks full transparency.

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

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

The description is well-organized with sections, bullet points, and examples. It is concise, front-loaded with the core purpose, and every sentence adds value without being verbose.

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

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

Given no output schema and no annotations, the description covers purpose, usage, parameters, and examples. It lacks an explanation of the return value format, which would complete the context for an agent. Still, it is quite thorough for a simple tool.

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

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

Schema description coverage is 100% (both parameters described). The description adds value by providing examples for 'type' (latest/finalized) and explaining 'network' as a name or alias. It reinforces schema info with context.

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.' The verb 'Get' and resource 'latest indexed head block or slot' are specific. The examples and sibling list show differentiation from other query tools.

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

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

The description includes explicit sections 'FIRST CHOICE FOR', 'WHEN TO USE', and 'DON'T USE', providing clear context on when to use this tool (e.g., before building a manual block range) and when not to (e.g., wanting to check if network is caught up).

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

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

Discloses the outputs: freshness, lag, heads, available tables. No annotations exist, so description carries full burden. It doesn't specify side effects or permissions, but as a read-only query, it's safe. Slightly lacking explicit mention of no destructive behavior, but still 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?

Well-structured with sections: description, common asks, first choice, when to use, don't use, examples. Front-loaded with main purpose. Every sentence adds value, no redundancy.

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

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

Given simple input schema (1 param) and no output schema, the description fully explains return values and usage context. Example input shows how to call the tool. Sufficient for an agent to use correctly.

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

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

Schema description coverage is 100% for the single parameter 'network'. Description doesn't add extra meaning beyond the schema's 'Network name or alias'. Baseline 3 is appropriate, as no compensation needed.

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

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

The description clearly states the tool answers whether a network is caught up, providing indexing freshness, lag, heads, and tables. It uses a specific verb ('check') and resource, distinguishing it from siblings like portal_get_head which only returns head.

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

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

Explicitly provides when to use (checking indexing status before querying, need chain family) and when not to use (only need latest block/slot). Also includes 'first choice for' and examples. This is comprehensive guidance.

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

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

No annotations exist, so the description carries the full burden. It discloses that the tool returns a bounded, recent evidence timeline with chronological paging and is non-destructive. However, it does not elaborate on the exact output format or pagination behavior, leaving some ambiguity about the response structure.

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 (summary, common asks, first choice, when/don't use, examples). Every sentence adds value, and the layout is scannable. It is appropriately sized for the tool's complexity.

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

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

While the description thoroughly covers usage and parameter guidance, it lacks details about the response format. With no output schema, the agent is left guessing what fields are returned, which is a notable gap for effective 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 minimal extra meaning beyond the schema; it provides example parameter values but does not explain cursor usage or timestamp formats 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 retrieves a simple recent-activity feed across multiple networks with chronological paging and investigation pivots. It distinguishes from sibling raw query tools by positioning itself as the first choice for recent activity, making the purpose unambiguous.

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

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

The description explicitly provides 'FIRST CHOICE FOR', 'WHEN TO USE', and 'DON'T USE' sections, clearly indicating appropriate contexts and exclusions. Examples further clarify usage patterns, and sibling tools are implicitly differentiated as raw query alternatives.

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

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

No annotations provided, so description carries full burden. Discloses aggregation, default window, compare_previous, mode depth. Minor lack: no mention of rate limits or response size, but adequate.

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

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

Well-structured with headings and examples. Front-loaded with core purpose. Concise yet informative for a complex tool.

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

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

Covers all key aspects: common asks, when to use, examples. No output schema but description not expected to compensate. Complete for a time-series 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 100% so baseline 3. Description adds value with examples and clarifies mode parameter meaning beyond enum. Defaults explained.

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

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

Clearly states it builds simple activity charts and time-series views. Specific verb 'build' and resource. Distinguishes from siblings like OHLC tools.

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

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

Explicit WHEN TO USE and DON'T USE sections with concrete alternatives (raw record lists, DEX pool candles). Provides default behavior hints.

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, but description adequately discloses that it aggregates and summarizes data. Mention of fast/deep modes in parameters adds transparency. No contradictions.

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

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

Well-structured with clear sections, front-loaded purpose, and no wasted sentences. Each section earns its place.

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

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

Given 11 parameters and no output schema, the description covers use cases, examples, and trade-offs well. Some missing details on return format, but overall sufficient.

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 3. Examples in description add practical context for typical parameter combinations, enhancing value beyond schema.

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

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

Clearly states it summarizes wallet activity and fund flow, with specific use cases like suspicious wallet triage. Distinguishes from siblings by being a high-level summary, not raw records.

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

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

Explicit WHEN TO USE and DON'T USE sections, plus FIRST CHOICE FOR and COMMON USER ASKS. Clearly guides when to use this tool vs. 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 given, so the description must carry the full burden. It does not explicitly state the tool is read-only, non-destructive, or any authentication/rate-limit requirements. However, the description and parameter 'response_format' imply it is a read operation returning aggregated analytics. For a complete picture, explicit behavioral statements would be beneficial.

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

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

The description is concise and well-structured with clear headings (COMMON USER ASKS, WHEN TO USE, DON'T USE, EXAMPLES). Every sentence adds value without redundancy, and the length is appropriate for the tool's complexity.

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

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

Given the 9 parameters and no output schema, the description covers the main purpose, usage guidance, and examples. It lacks details about the output structure (only mentioned as sections). For a more complete picture, describing the return format or key fields would help, but it is adequate for an analytics tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by listing output sections (top traders, volume by coin, fees, PnL) which maps to what parameters like 'response_format' control. The examples show common parameter combinations, aiding understanding beyond 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 clearly states it fetches aggregate Hyperliquid fill analytics including top traders, volume, fees, and PnL. The verb 'Get' and specific resource 'big-picture Hyperliquid fill analytics' are precise. It distinguishes itself from siblings like portal_hyperliquid_query_fills (individual fills) and portal_hyperliquid_get_ohlc (candles) by emphasizing aggregate, network-level data.

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

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

Explicit WHEN TO USE and DON'T USE sections are provided, telling the agent exactly when to choose this tool (network-level analytics, want top traders/volume/fees/PnL) and when not to (need individual fills or OHLC candles). Examples further clarify typical use cases.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool uses fills to produce OHLC, volume, and VWAP data. It explains the auto interval mapping and mentions fixed buckets. It does not explicitly state it is read-only or mention auth/rate limits, but covers core behavior well.

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 sections for purpose, common asks, usage guidance, and examples. It is concise, front-loaded with the key function, and every sentence adds value with no 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?

Despite lacking an output schema, the description explains the return data (candles with OHLC, volume, VWAP). It covers purpose, parameters, usage guidelines, and provides an example, making it complete for an agent to select and invoke.

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

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

Schema coverage is 100% with each parameter described. The description adds value by explaining the optionality of coin with cursor, detailing interval auto ranges, and providing an example. This exceeds the baseline of 3 for high coverage.

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

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

The description clearly states the tool builds chart-ready OHLC candles with fixed buckets and auto intervals. It uses specific verbs and resources, and the common user ask example (BTC candles) further clarifies. It distinguishes from siblings like portal_hyperliquid_query_fills and portal_hyperliquid_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 includes explicit 'WHEN TO USE' and 'DON'T USE' sections, providing clear guidance on when to use this tool vs alternatives. It specifies to use for candles for one coin on Hyperliquid, and not for scalar time-series buckets or raw fills.

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

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

No annotations are provided, so the description carries the full burden for behavioral disclosure. It implicitly indicates read-only through the name 'query' and mentions returning raw records, but does not explicitly state that it doesn't modify state, nor does it cover rate limits, authorization needs, or side effects. It adds some context about filtering capabilities but lacks comprehensive transparency.

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

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

The description is well-structured with clear sections (main description, user asks, when/don't use, examples). It is concise, using bullet points and direct language, and every sentence adds value without redundancy.

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

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

Given 18 parameters with 100% schema coverage and no output schema, the description is fairly complete. It includes usage guidance, examples, and covers key contextual aspects. However, it does not detail return values or pagination behavior beyond the cursor parameter, leaving 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 description coverage is 100%, so the schema already documents all parameters well. The description provides a brief common use case and examples, but does not add significant meaning beyond what the parameter descriptions already convey. It does not explain relationships or provide additional syntax details.

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

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

The description clearly states the tool's purpose: 'Query raw individual Hyperliquid fills with trader, coin, fee, PnL, and builder context.' It uses specific verbs and resources, and distinguishes from siblings like portal_hyperliquid_get_analytics by emphasizing raw versus aggregated data.

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

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

The description provides explicit 'WHEN TO USE' and 'DON'T USE' sections, including detailed conditions and alternatives such as using portal_hyperliquid_get_analytics for aggregates or portal_hyperliquid_get_ohlc for candles.

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?

Although no annotations are provided, the description implies a safe, read-only discovery operation through its examples and use cases. It does not explicitly state non-destructiveness or lack of side effects, but the context (listing/finding networks) strongly suggests it. A 4 is appropriate as it is largely transparent.

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

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

The description is well-structured with clear sections (purpose, common asks, usage rules, examples). It is concise yet comprehensive, with no wasted words. Every sentence adds information.

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

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

Given the tool is a simple list/discovery operation with no output schema, the description covers purpose, parameters, usage, and examples thoroughly. It is complete enough 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 coverage is 100%, but the description adds significant value with concrete examples (e.g., 'query':'base', 'vm':'solana','network_type':'mainnet') showing how to combine parameters. This practical guidance exceeds what the schema alone provides.

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

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

Description clearly states the tool finds the right network or chain name across multiple VM families (EVM, Solana, Bitcoin, Substrate, Hyperliquid). It gives concrete examples of user asks and distinguishes itself from sibling tools that query specific network data.

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

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

Explicitly spells out when to use ('FIRST CHOICE', 'WHEN TO USE') and when not to ('DON'T USE'), with clear criteria like being unsure of the network name or wanting to filter by VM/network type. This provides unambiguous 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 full burden. While it explains the core function and gives examples, it does not disclose behavioral traits like idempotency, rate limits, or result format. It lacks explicit safety or read-only hints.

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

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

The description is well-structured with clear sections and examples. It is informative but slightly verbose; a few sentences could be trimmed without losing meaning. Overall, it is appropriate for the tool's complexity.

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

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

The description covers common use cases, when to use, and examples. It lacks details on return format and error handling, but given the tool's purpose (resolution), it is reasonably complete. No output schema exists, so some ambiguity remains.

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

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

Schema description coverage is 100% with good parameter descriptions. The description adds value by providing usage context and examples (e.g., kind values, query formatting) beyond the schema, though the schema already does a solid job.

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 resolves user-facing blockchain entities into query-ready identifiers. It lists specific use cases like token symbols, contract aliases, and protocol names, distinguishing it from sibling tools that perform queries or 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 guidance with 'FIRST CHOICE FOR', 'WHEN TO USE', and 'DON'T USE' sections. It tells the agent exactly when to invoke the tool and when not to, such as when addresses are already known.

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

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

No annotations provided, so the description carries full burden. It discloses performance implications (include_programs requires extra scan, include_compute_units disabled by default for speed) and explains mode behavior. However, it does not mention authentication, rate limits, or return format 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?

Well-structured with clear sections (COMMON USER ASKS, FIRST CHOICE FOR, WHEN TO USE, DON'T USE, EXAMPLES). Every sentence adds value; no redundancy. Front-loaded with key 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?

Given 10 parameters and no output schema, the description covers purpose, usage scenarios, and performance trade-offs. It lacks explanation of return values or error handling, but overall provides sufficient context for selection and basic usage.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds usage context (e.g., 'Include top programs' in COMMON USER ASKS) and examples with parameter values, but does not provide details beyond the schema descriptions for individual parameters.

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

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

The description clearly states the tool retrieves 'the big picture for Solana throughput, fees, wallet activity, and optional top-program usage.' It uses a specific verb ('Get') and resource ('big picture'), and distinguishes from siblings like raw transaction queries by emphasizing aggregated analytics. The 'FIRST CHOICE FOR' section reinforces the 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?

Dedicated 'WHEN TO USE' and 'DON'T USE' sections explicitly guide when to select this tool (e.g., 'big picture for Solana right now') and when not to (e.g., 'chart buckets or raw transaction/instruction records'). Examples further clarify common use cases.

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 cover behavioral traits. It implies read-only nature ('Query') but does not explicitly state it is non-destructive, nor does it mention authentication, rate limits, or error handling. Cursor-based pagination is mentioned but not explained.

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

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

The description is well-structured with headings (COMMON USER ASKS, WHEN TO USE, DON'T USE, EXAMPLES) and is concise. Every sentence adds information, and the example is directly useful. No redundant text.

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 the tool (39 parameters, no output schema), the description covers the main use cases and provides an example. However, it lacks an explanation of the return format (what fields are returned) and does not detail pagination behavior beyond mentioning a cursor. Slightly incomplete for a tool of this complexity.

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

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

Schema coverage is 100% with each parameter having a description. The tool description adds value beyond the schema by providing an example that demonstrates typical usage (e.g., program_id, network, timeframe, limit), giving semantic context for how parameters interact.

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 instructions with program and account filters. It lists a common use case (Token Program instructions) and distinguishes from sibling tool portal_solana_query_transactions by explicitly stating not to use when only transaction-level activity is needed.

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, provides an example with concrete parameter values, and implicitly contrasts with transaction-level queries handled by a sibling tool.

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

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

No annotations exist, so the description must convey behavior. It mentions optional include flags, response formats, and query capabilities. However, it does not explicitly state read-only nature or side effects, and the misleading example slightly reduces transparency.

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

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

The description is well-structured with headers and a front-loaded purpose, but it is lengthy and contains an inaccurate example. It could be more concise without losing clarity.

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 17 parameters and no output schema, the description omits important details like pagination (cursor usage), relationship between block/timestamp filters, and response format specifics. The erroneous example undermines completeness.

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

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

Schema descriptions cover all parameters at 100%, setting a baseline of 3. However, the description's example uses 'program_id' which is not in the schema, likely causing confusion. No additional semantic value is provided beyond what the schema already offers.

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

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

The description clearly states the verb 'Query' and the resource 'raw Solana transactions' with optional inclusions. It distinguishes itself from sibling query tools by being Solana-specific and targeting raw transactions.

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

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

The 'WHEN TO USE' and 'DON'T USE' sections explicitly guide selection, noting when to prefer this tool over convenience tools or recent activity queries. Alternatives are implied via sibling 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?

No annotations provided, so description carries full burden. It effectively communicates it's a read-only analytics snapshot (no destructive actions) and describes output contents (counts, top names). Lacks explicit mention of response structure or error behavior, but covers core behavior well.

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

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

Well-structured with headings but somewhat repetitive (e.g., FIRST CHOICE FOR overlaps with WHEN TO USE). Could be tightened without losing clarity.

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 (all optional) and no output schema, description provides sufficient context: explains output contents, response_format parameter, and usage scenarios. Missing explicit response shape but adequate 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%, baseline 3. Description adds value by explaining mode defaults, timeframe options, and from_block vs timeframe usage, along with examples showing parameter combinations. Exceeds 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 clearly states it provides an 'Analytics snapshot for Substrate or Polkadot activity' with counts and top event/call names, distinguishing it from sibling tools like portal_substrate_query_events that return raw records.

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

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

Includes explicit 'WHEN TO USE' and 'DON'T USE' sections, common user asks, and examples, providing clear guidance on when to invoke this tool vs alternatives like portal_substrate_query_calls or portal_substrate_query_events.

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

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

No annotations provided, so description carries full burden. It mentions return of raw call rows, optional inclusion of events/subcalls/extrinsic, and response format options (compact mode). Could be improved with performance or pagination details, but sufficient.

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

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

Well-structured with sections and bullet points. Information is front-loaded. Slightly verbose but each sentence adds value; could be trimmed slightly.

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 15 parameters and no output schema, the description covers purpose, usage, examples, and exclusions. Lacks output structure details but provides enough context for an AI agent to use effectively.

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% (baseline 3). The description adds concrete examples for parameters like call_names and timeframe, and explains response_format behavior, going beyond basic 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 explicitly states it queries raw Substrate or Polkadot calls with filters, and the examples reinforce this. It clearly distinguishes from sibling tools like portal_substrate_query_events by emphasizing calls vs events.

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

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

Provides explicit 'WHEN TO USE' and 'DON'T USE' sections, along with 'FIRST CHOICE FOR' and common user asks. Examples illustrate appropriate use cases.

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

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

No annotations provided, so description carries full burden. It discloses filtering, optional context inclusion, and response format, but does not explicitly mention read-only nature or authentication requirements.

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

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

Well-structured with sections and bullet points. Every sentence provides useful information. Front-loaded with the main action and contextual sections.

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 14 parameters and no output schema, the description covers usage context, examples, and behavioral details. Lacks explicit mention of return structure but is otherwise 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%, but description adds value through examples (e.g., event_names format) and explanation of response_format. The example usage clarifies parameter combinations.

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

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

Description clearly states the tool queries raw Substrate or Polkadot event rows with pallet/event-name filters and optional context. It distinguishes from siblings by specifying 'raw event rows' and providing examples like Balances.Transfer.

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 sections for COMMON USER ASKS, FIRST CHOICE FOR, WHEN TO USE, and DON'T USE provide clear guidance on when to choose this tool over alternatives like calls or aggregate analytics.

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