SQD Portal MCP Server
OfficialServer Quality Checklist
Latest release: v0.7.9
- Disambiguation5/5
Each tool has a clearly distinct purpose, targeting specific networks and actions. Even within the same network, tools like query_transactions, query_logs, and query_token_transfers for EVM are well-separated by their focus on raw transactions, event logs, and token transfers respectively. Debug tools are explicitly marked as advanced, reducing confusion.
Naming Consistency4/5The naming follows a mostly consistent pattern: portal_{network}_{action} for network-specific tools. However, cross-network utilities like portal_get_head, portal_list_networks, and portal_resolve_entity deviate from this pattern, and the debug tools use a 'debug_' prefix instead of placing it after the network. These minor inconsistencies prevent a perfect score.
Tool Count4/5With 28 tools, the server covers multiple blockchain networks (Bitcoin, EVM, Solana, Hyperliquid, Substrate) with comprehensive analytics, raw queries, and utilities. While on the higher side, the tools are logically grouped per network and purpose, justifying the count without feeling bloated. A slight reduction in debug tools could be argued, but overall it is appropriate.
Completeness5/5The tool surface is highly complete for a blockchain data indexer. Each network has analytics, raw query tools, and specialized features (OHLC for EVM/Hyperliquid, wallet summaries, time series). Cross-network utilities like network listing, entity resolution, and recent activity feed cover common use cases. Debug tools add depth. There are no obvious gaps for the intended domain.
Average 4.3/5 across 28 of 28 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
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 disclose behavioral traits such as being read-only, rate limits, or authentication requirements, beyond implying a query operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, common asks, usage guidelines, and examples. It is front-loaded and each section adds value without being overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite missing output schema, the description explains response format options and provides examples covering common cases. It addresses pagination and contextual options adequately for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the schema already documents all parameters. The description adds examples but not significant additional meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query raw Solana transactions with optional balances, rewards, logs, and instruction context', providing a specific verb and resource. It implies differentiation from convenience tools but doesn't explicitly name sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The WHEN TO USE and DON'T USE sections give explicit guidance: use when needing raw Solana records and specific filters, avoid when only recent activity or compact summary is needed. Lacks specific alternative tool names but still useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates the tool is read-only (builds from fills) and mentions pagination via cursor, but does not explicitly state it is side-effect-free, auth needs, or rate limits. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (COMMON USER ASKS, WHEN TO USE, DON'T USE, EXAMPLES). Mostly concise, though COMMON USER ASKS is very brief and the example is partially redundant with schema. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema, so return format is not described (only 'chart-ready'). With 6 parameters and no output details, the description is functional but could be more complete for a data-fetching tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. The tool description adds minimal extra value beyond schema (e.g., example default duration, auto interval mapping). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Build chart-ready' and resource 'Hyperliquid trade OHLC candles', and distinguishes from sibling tools like portal_hyperliquid_get_analytics and portal_hyperliquid_query_fills by specifying candles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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 candles for one coin, need chart-ready data; avoid for scalar time-series buckets or raw fills. However, it does not name specific sibling alternatives, slightly reducing clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must compensate. It describes high-level behavior (summarizes interactions, callers, events) and mentions execution modes ('fast' vs 'deep'), but lacks details on permissions, rate limits, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with headings, bullet points, and an example. A few sections could be condensed, but overall it's clear and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and usage well, but lacks information about the return format or structure. With 7 parameters and no output schema, a brief note on expected output would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description. The description adds examples and clarifies 'timeframe' vs block count, but largely restates schema info. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool summarizes recent contract activity including interactions, unique callers, and events. It uses specific verbs ('summarize', 'analyze') and distinguishes itself from siblings like raw log queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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. It specifies it's the 'FIRST CHOICE FOR' contract activity snapshots and advises against using when raw logs or general network activity are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the tool's output and supported data sources but does not disclose potential behavioral traits like rate limits, data freshness guarantees, or error handling. However, it clarifies that it produces candles from event-derived sources, which is sufficient for an agent to understand the core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections (common asks, when/don't use, examples). It is front-loaded with a concise summary. While somewhat lengthy, every section serves a purpose; minor verbosity in examples is acceptable for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description sufficiently indicates the return type: 'chart-ready OHLC candles plus a recent trade tape'. It covers all key aspects—supported sources, parameters, usage scenarios, and examples—making it complete 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.
Parameters3/5Does 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 providing real-world examples with JSON payloads for different sources, but the individual parameter descriptions in the schema already explain each field. The description does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Build chart-ready EVM OHLC candles plus a recent trade tape from supported DEX event sources', using specific verb and resource. It lists supported sources (Uniswap v2, v3, v4, Aerodrome Slipstream) and distinguishes from siblings that focus on analytics, logs, or transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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, guiding when OHLC candles are appropriate vs scalar metrics. While alternative tool names are not mentioned, context from siblings (e.g., portal_evm_get_analytics, portal_get_time_series) provides implicit alternatives. The guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the tool as aggregating data but does not explicitly state it is read-only, mention side effects, authorization needs, or rate limits. For a read-only analytics tool, this omission leaves behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with distinct sections: main description, COMMON USER ASKS, WHEN TO USE, DON'T USE, EXAMPLES. It is concise (4 sentences plus examples) and front-loaded with the core purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 optional parameters, no output schema, and no annotations, the description covers the main aspects: what the tool returns (aggregate sections), what it doesn't (individual fills, OHLC), and provides usage examples. It lacks behavioral details but otherwise is fairly complete for an analytics tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions in the input schema. The tool description adds examples but does not provide significant additional meaning beyond the schema. Baseline 3 is appropriate as the schema already documents parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the big-picture Hyperliquid fill analytics with top traders, volume by coin, fees, and PnL.' It uses a specific verb ('Get') and resource ('big-picture Hyperliquid fill analytics'), and distinguishes from siblings like portal_hyperliquid_query_fills (individual fills) and portal_hyperliquid_get_ohlc (OHLC). COMMON USER ASKS and EXAMPLES reinforce this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
A dedicated 'WHEN TO USE' section lists use cases (network-level analytics, top traders, volume, fees, PnL, aggregated sections), and a 'DON'T USE' section explicitly excludes individual fills and OHLC candles. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as 'ADVANCED' and 'debugging' but does not disclose behavioral traits beyond that, such as side effects, data volume implications, or response structure. With no annotations, more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (main statement, common asks, when/don't use, examples). It is concise and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and no output schema or annotations, the description could be more complete. It explains purpose and usage well but lacks details on return format, pagination, or potential limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 provides an example usage (network, timeframe, limit) but does not add significant new meaning beyond the parameter descriptions in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries raw block records for EVM, Solana, or Bitcoin. It distinguishes from siblings by specifying raw block records instead of transactions, logs, or summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 versus alternatives, including specific examples like debugging coverage or raw block needs, and when to prefer other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 mentions filtering but does not describe pagination behavior (cursor is in schema but not covered), latency implications, or whether the tool is read-only. The timeframe hint about Solana slots is helpful but insufficient for a complete behavioral picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and well-structured with clear headings (common asks, when/don't use, examples). The main purpose is front-loaded. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (39 parameters, no output schema), the description fails to explain return structure or the interaction between filters. The example is helpful but does not clarify output format, pagination limits, or combined use of multiple filters. Completeness is adequate for basic use but lacks depth for complex queries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 minimal parameter-specific meaning beyond the schema, though the example partially illustrates how program_id and timeframe are used. No additional semantics for the numerous account index or discriminator parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries raw Solana instructions with program and account filters. It distinguishes from transaction-level queries via the 'DON'T USE' section, establishing differentiation from sibling tools like portal_solana_query_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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, clearly specifying appropriate contexts and providing an example that demonstrates typical usage with parameters like network, timeframe, program_id, and limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It clearly implies read-only querying, describes optional inline input/output attachment, and mentions response format options (compact mode). However, it does not explicitly state non-destructive nature or discuss pagination limits beyond cursor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: main action, common asks, when/don't use, examples. Front-loaded with key purpose. Examples add length but are instructional. Minor redundancy in common asks section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers usage context well with examples and guidelines. However, no output schema is provided, and the description only mentions 'UTXO envelope' without detailing the response structure. Pagination behavior beyond cursor parameter is not explained, leaving some gaps for a tool with 12 optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (100%), so baseline is 3. The description adds value through examples showing parameter combinations and explaining behavior like 'Compact mode keeps inline inputs and outputs in a smaller shape,' but does not introduce new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query raw Bitcoin transactions' with a specific verb and resource. It distinguishes from sibling tools like portal_evm_query_transactions by specifying Bitcoin and focusing on raw transaction records including UTXO envelopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides distinct WHEN TO USE and DON'T USE sections. Explicitly warns against using for wallet/network summaries, implicitly directing to alternatives like portal_get_wallet_summary. Examples illustrate common use cases and parameter combinations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It implies read-only via 'Query', but does not explicitly state safety, rate limits, or other behavioral traits. Minimal extra disclosure beyond the operation type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (common asks, when/don't use, example). Every sentence adds value, front-loaded with purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters and no output schema, description effectively covers scope, usage, and provides an example. Could mention output format, but overall complete enough for a query tool with good schema documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds only an example usage, not additional meaning beyond what schema provides. Example is helpful but not extensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 contrasts with fills/analytics, distinguishing it from sibling tools like 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.
Usage Guidelines5/5Does 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 replica-command records, avoid for public trading activity (fills/analytics better suited).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the basic behavior but does not disclose side effects, rate limits, or idempotency. It mentions 'ambiguity kept explicit' but does not elaborate how.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, though there is some overlap between 'FIRST CHOICE FOR' and 'WHEN TO USE'. Generally concise and front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is comprehensive enough for an AI agent to decide when to use this tool and how to invoke it, covering purpose, usage guidelines, and examples. No output schema is needed, and the inputs are fully covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are well-documented in the schema. The description adds usage context through examples but does not introduce new semantic details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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, explicitly listing common asks and differentiating from sibling tools that query blockchain data directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit sections for when to use (e.g., resolving token symbols, contract aliases) and when not to use (e.g., if exact address is already known), giving 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.
- Behavior3/5
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 including top programs requires an extra scan and is slower, and that include_compute_units is disabled by default for speed. However, it does not explicitly state whether the operation is read-only or mention any side effects, rate limits, or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections like 'FIRST CHOICE FOR', 'WHEN TO USE', 'DON'T USE', and 'EXAMPLES'. It is concise yet informative, front-loading the main purpose, 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, no output schema), the description covers the tool's purpose, usage guidelines, and behavioral nuances like performance implications. It provides examples but could be more complete by describing the response structure or return value format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 overall context and examples but does not provide additional parameter-level detail beyond what the schema already offers. The examples illustrate correct usage but do not enhance parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the big picture for Solana throughput, fees, wallet activity, and optional top-program usage. It specifies the verb and resource, and the 'FIRST CHOICE FOR' and sibling tool names distinguish it from other network-specific tools like portal_bitcoin_get_analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 choose this tool over alternatives. It also gives examples of user asks, guiding the AI agent on appropriate scenarios like network health snapshots.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 indicates the tool is a read-only 'snapshot' or 'health check' with no mention of side effects, which is adequate for an analytical tool. It also describes execution depth modes ('fast' vs 'deep') and response formats, adding behavioral context 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with multiple sections ('COMMON USER ASKS', 'FIRST CHOICE FOR', 'WHEN TO USE', 'DON'T USE') that overlap in content. It could be streamlined without losing clarity. However, the key information is front-loaded and the structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value (counts and top names) and mentions response formats. It also provides examples that illustrate expected inputs. The description covers the essential aspects for an agent to understand the tool's purpose and outputs, though it could be slightly more comprehensive about edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 does not significantly enhance parameter understanding beyond the schema's own descriptions, though the 'EXAMPLES' section shows typical usage patterns, which adds some value. The parameter descriptions in the schema are already detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides an 'analytics snapshot' with event, call, and extrinsic counts plus top names. It differentiates from sibling tools like portal_substrate_query_calls and portal_substrate_query_events by specifying that it returns aggregated analytics rather than raw rows, and provides examples of common user asks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 specific scenarios such as wanting a quick network health check or top pallet events vs. needing full raw records. It also indicates it is the first choice for polkadot activity analytics, providing clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It describes what the tool does but does not disclose behavioral traits such as rate limits, authentication requirements, or performance characteristics. The description implies a read-only operation, but lacks explicit safety guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections, making it easy to scan. The opening line is front-loaded with the core purpose. However, there is slight redundancy (e.g., 'raw Substrate or Polkadot event rows' appears multiple times), preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (14) and no output schema, the description provides ample context: usage guidance, an example, and notes on optional parameters like include_call and include_stack. It fully equips the agent to understand when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning the input schema already describes all parameters. The description adds a usage example and common user asks, but does not provide new semantic meaning beyond what the schema offers. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries raw Substrate or Polkadot event rows with pallet/event-name filters and optional context. It includes a common user ask and an example, distinguishing it from sibling tools like portal_substrate_query_calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 appropriate usage, including when to avoid the tool. It implies alternatives by mentioning 'calls or aggregate analytics' in the don't-use clause, and the sibling tool list provides concrete alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It mentions that include_address_activity requires extra queries and is slower, which is useful. However, it does not explicitly state that the operation is read-only or safe, nor does it disclose any other behavioral traits like rate limits or destructive potential. A higher score would require more explicit safety or performance notes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections and front-loaded key information. However, it has some redundancy (e.g., 'COMMON USER ASKS' and 'FIRST CHOICE FOR' overlap with 'WHEN TO USE'). Could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 optional parameters, no output schema, and high schema coverage, the description covers the main use cases, provides examples, and explains when to use. It is complete enough for an agent to understand the tool's purpose and invocation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 with a concrete example using 'timeframe' and 'network', and the 'WHEN TO USE' section references timeframe. The parameter descriptions in the schema are also quite detailed (e.g., mode explanation). This exceeds the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get the big picture for Bitcoin block, fee, and address activity over a recent or explicit window.' This is a specific verb-resource combination, and the description distinguishes it from sibling tools like portal_bitcoin_query_transactions and other analytics tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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, providing clear context and alternatives. For example, it advises against using when raw transactions are needed, directing to a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, but description discloses query behavior, response format options, filtering capabilities, and optional inclusion of events, subcalls, extrinsic, and stack. Does not cover rate limits or pagination limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with sections and examples, front-loaded with main purpose. No superfluous text, but length is reasonable given complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters and no output schema, description provides sufficient context on filtering, response options, and examples. Lacks details on output structure but hints at it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds marginal value beyond schema. Examples show usage patterns and explain default response_format, but most parameter semantics are already in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries raw Substrate or Polkadot calls with filter options, differentiates from the sibling portal_substrate_query_events, and includes specific examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit sections 'FIRST CHOICE FOR', 'WHEN TO USE', and 'DON'T USE' provide clear guidance on appropriate use cases and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions 'nearest indexed block or slot', implying approximate matching, and gives input examples. Could disclose more about out-of-range timestamps or limitations, but sufficient for a debug tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with labeled sections (ADVANCED, COMMON USER ASKS, WHEN TO USE, DON'T USE, EXAMPLES). Each sentence earns its place; no fluff. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (2 params, no output schema, no annotations), the description covers purpose, usage, and examples comprehensively. Missing details on return value format, but acceptable for a debug tool. Leaves little ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters fully described. The description adds example values and clarifies that timestamp accepts various formats, but this is already in the schema. Baseline 3 applies due to high coverage; examples add marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Resolve a timestamp to the nearest indexed block or slot', using a specific verb and resource. It distinguishes from sibling tools like portal_debug_query_blocks by focusing on time-to-block resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains explicit 'WHEN TO USE' and 'DON'T USE' sections with clear context (debugging, building manual queries) and alternatives (other tools accept timestamps directly). Examples reinforce proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 adds context that the tool returns ranked contracts and overview metrics, not raw records. However, it does not explicitly disclose mutability or safety, but the name 'get_analytics' implies read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, front-loaded purpose, and an example. Every sentence adds value, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no output schema, and no annotations, the description covers purpose, usage, and examples well. It lacks detailed output format, but the example gives some indication of expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description includes an example that demonstrates typical parameter usage (network, timeframe, limit), complementing the schema but not adding significant new semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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,' using a specific verb and resource. It distinguishes from sibling tools like portal_hyperliquid_get_analytics by focusing on EVM networks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'FIRST CHOICE FOR', 'WHEN TO USE', and 'DON'T USE' sections, providing clear guidance on when to choose this tool over others (e.g., for network overview rather than time buckets). It also gives a common user ask example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses performance characteristics (recommend <10k blocks for speed), field presets for context reduction, and scanning order. While read-only is implicit, no destructive actions are indicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections and front-loaded summary. Uses bullet points and examples effectively. Some redundancy but overall concise given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should explain return structure. It hints at decoded logs but doesn't fully describe output. Cursor usage mentioned but not elaborated. High parameter coverage partially compensates, but lacks output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 24 parameters have descriptions in the schema (100% coverage). The description adds value by explaining event aliases, scan_order usage, field_preset effects, and token_symbols resolution, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 EVM logs with address/topic filters, common event aliases, earliest/latest scanning, and optional inline decoding.' It includes specific use cases like NFT mint lookups and distinguishes from 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.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit WHEN TO USE conditions (5 points), a DON'T USE section (token transfer tool), and concrete examples. This guides the agent effectively on when to choose 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.
- Behavior3/5
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 explains the tool returns the latest head block or slot but does not explicitly state that it is a read-only operation, nor does it describe response structure or any side effects. While the tool is simple, the lack of explicit read-only indication leaves some transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (COMMON USER ASKS, FIRST CHOICE, WHEN TO USE, DON'T USE, EXAMPLES) that front-load key information. While slightly lengthy, every section adds value, and the overall structure aids quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 is remarkably complete. It defines purpose, usage boundaries, and provides examples. It does not describe return values, but that is acceptable when no output schema is present and the tool returns a simple numeric value. No additional context seems necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds meaningful context beyond the schema: it provides concrete examples of network values and explains the 'type' parameter's default and enum options. This helps agents understand parameter usage beyond what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get just the latest indexed head block or slot for a network,' providing a clear verb and specific resource. It distinguishes itself from siblings by positioning as 'FIRST CHOICE FOR...' and listing what not to use, demonstrating clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use ('You only need the current block or slot number.'), when not to use ('You want to know if the network is caught up...'), and positions it as first choice for a specific scenario. Examples further clarify usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure. It explains the tool returns status information (freshness, lag, heads, tables) but does not explicitly state it is read-only or requires no authentication. The context implies it is a safe query, but explicit mention of being non-destructive 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (common user asks, first choice for, when-to-use, don't use, examples). It is concise, front-loaded with the core purpose, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately explains inputs and the nature of outputs (indices freshness, lag, heads, tables). However, it lacks a detailed structure of the response, which would be helpful for an agent processing the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter 'network' described as 'Network name or alias'), so baseline is 3. The description adds an example ('network': 'base-mainnet') and context ('Is Base caught up?') but does not provide additional semantic meaning beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool answers 'is this network caught up?' with indexing freshness, lag, heads, and available tables. It specifies 'FIRST CHOICE FOR: checking indexing head, lag, tables, and capabilities for one network', distinguishing it from siblings like portal_get_head (which likely returns only head block) and portal_list_networks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 examples. It advises using when you want to know if a network is indexed or caught up, and not to use if you only need the latest block or slot number. This helps an agent choose correctly among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 produces a summary with shared overview, asset movement, counterparties, and evidence pivots. However, it does not mention pagination or rate limits, which would enhance transparency for a tool with 11 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (COMMON USER ASKS, FIRST CHOICE FOR, WHEN TO USE, DON'T USE, EXAMPLES). Every sentence provides value without redundancy, and the formatting aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 provides adequate context about purpose, usage, and examples. It mentions key output components (counterparties, evidence pivots), but lacks detail on return format or error handling, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds marginal value beyond the schema. The examples illustrate parameter usage, but the schema already documents each parameter well. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool summarizes wallet activity and fund flow, and distinguishes itself from sibling tools that focus on raw records or specific chain queries. The 'FIRST CHOICE FOR' and 'DON'T USE' sections further clarify its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 appropriate scenarios, such as suspicious wallet triage, and explicitly state when to avoid (need for raw records). Examples further reinforce correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 adequately describes the query behavior, including optional includes and aggregation, but does not explicitly state that it is a read-only operation (though implied). It otherwise is transparent about capabilities and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is 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 main purpose. Though verbose, each section adds value without redundancy. Minor improvement could be trimming the examples further.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 35 parameters, no output schema, and no annotations, the description covers all major use cases with examples and guidelines. It addresses parameter combinations, limits, and field presets. However, it does not detail the output format or pagination behavior beyond cursor, which is left to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 grouping parameters into common use cases, providing example JSON values, and explaining advanced features like token symbol resolution and aggregation. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries raw EVM transactions with optional context like logs, traces, and state diffs. It distinguishes from sibling tools like portal_evm_query_logs and portal_evm_query_token_transfers by focusing on raw transaction records and exposing chain-specific fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 specific use cases (e.g., raw transaction records, first transactions by type, top-N by metrics) and excluding quick feeds or wallet summaries. It also includes concrete examples for each scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes default duration, execution modes (fast/deep), and comparison behavior, but does not explicitly state read-only nature or authorization needs. Adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is 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). Each sentence serves a purpose. Front-loaded with main purpose. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Rich context for a complex 11-parameter tool: provides use cases, exclusions, parameter behaviors, and examples. However, absence of output schema means description could better explain the return format (e.g., structure of the bucket data). Still, overall comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds significant value beyond schema: explains default behaviors ('Defaults to 6h for interactive use'), acceptable formats ('compact durations like 30m or natural phrases'), and includes concrete examples that demonstrate parameter combinations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Build' and resource 'simple activity charts and other time-series views across supported VMs'. It distinguishes from siblings by mentioning specific use cases like 'compare-previous windows and grouped EVM contract trends' and contrasts with OHLC output in DON'T USE.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit sections 'FIRST CHOICE FOR', 'WHEN TO USE', and 'DON'T USE' provide clear guidance on when to select this tool over alternatives. Examples further 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for transparency. It discloses that the tool returns networks filtered by parameters like vm, network_type, real_time_only, query, and limit. It mentions 'real-time indexed head' filter but does not elaborate on what that means. Overall, it adequately describes the read-only, listing behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (COMMON USER ASKS, FIRST CHOICE FOR, WHEN TO USE, DON'T USE, EXAMPLES). It is front-loaded with the main purpose. Though slightly verbose (multiple sections), each part serves a clear role and adds information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, many siblings), the description provides sufficient context. It explains when to use this tool over siblings, covers common use cases, and gives examples. It does not detail the return format, but for a list tool, the examples implicitly show the kind of results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter documented. The description adds value beyond the schema by providing concrete examples of parameter usage (e.g., query: 'base', vm: 'solana', network_type: 'mainnet'). This helps agents understand how to combine parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to find the right network or chain name across multiple blockchain families. It uses specific verbs ('Find', 'Show') and explicitly lists supported VMs, distinguishing it from sibling tools that perform analytics or queries on specific networks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidelines: when to use (unsure of network names, filter by VM/type/availability) and when not to use (already know exact network). It also gives common user asks and example queries, making the usage context crystal clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It explains what the tool returns (deployer, deployment block, etc.) but does not disclose operational traits like idempotency or rate limits. The behavioral context is reasonable but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections, bullet points, and examples. It is moderately long but every section adds value. Could be slightly more concise, but overall good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and no output schema or annotations, the description covers common asks, usage guidelines, and multiple examples. It is complete and self-contained for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value via examples showing parameter combinations and default behaviors (e.g., search_depth_blocks=100000), and clarifies the role of 'contract' vs 'contract_address'. This justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Locate the create trace and parent transaction that deployed a specific EVM contract address within a bounded window.' It uses specific verb and resource, and distinguishes from sibling tools like portal_evm_get_contract_activity via DON'T USE guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit sections for 'FIRST CHOICE FOR:', 'WHEN TO USE:', and 'DON'T USE:' provide clear context, including specific alternatives like 'use portal_evm_get_contract_activity' and conditions for when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It explains the tool's purpose (querying transfers, no event signatures needed), scanning order, and timeframe usage. It does not mention potential rate limits, pagination behavior, or whether the tool is read-only, but these are reasonably inferred. Overall, good transparency for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is 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). It is concise with no redundant information, and the key advantage is front-loaded in the first sentence. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (15 parameters, no output schema, no annotations), the description covers most aspects: purpose, usage guidelines, parameter hints via examples, and differentiation from siblings. It could mention the output format (e.g., list of transfers with fields) but the tool name and examples provide sufficient context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 providing usage patterns and examples that show how to combine parameters (e.g., network, timeframe, token_symbols, scan_order for 'first recent USDC transfer'). This contextual guidance goes beyond the individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries token transfers on EVM networks, distinguishing it from sibling tools like portal_evm_query_logs which require raw event signatures. It uses specific language ('Query token-transfer activity', 'did token X move?') and highlights the benefit of not 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.
Usage Guidelines5/5Does 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 outline appropriate scenarios (e.g., ERC-20 transfers, tracing, fastest answer) and when to avoid (arbitrary event logs). Examples further clarify usage, and the sibling tool portal_evm_query_logs is implicitly suggested for other events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It mentions chronological paging, investigation pivots, and that it returns a recent feed. While it doesn't detail destructive behavior (unlikely), it lacks mention of rate limits or specifics about the returned data format, but is still quite transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, bullet points, and examples. It is front-loaded with the core purpose, and every sentence earns its place without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (0 required) and no output schema, the description covers usage guidance, examples, and parameter hints comprehensively. However, it does not describe the return format or fields, which would be helpful given the lack of output schema, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 value with examples clarifying the 'timeframe' and 'network' parameters ('1h', '6h', 'base-mainnet'), and explains 'cursor' for continuation, which goes beyond the schema comments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), the resource ('simple recent-activity feed'), and scope ('across EVM, Solana, Bitcoin, or Hyperliquid'), distinguishing it from sibling tools like portal_evm_query_transactions by emphasizing it as a high-level feed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit instructions with 'FIRST CHOICE FOR', 'WHEN TO USE', and 'DON'T USE' sections, covering when to choose this tool over raw query tools and when to avoid it (e.g., for raw logs or charts), which is exemplary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While no annotations exist, the description implies read-only operation and mentions cursor for continuation. It does not explicitly state safety traits like no side effects, but the behavioral context is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, no unnecessary text, and an example that demonstrates usage. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 18 parameters and no output schema, the description covers purpose, usage, and an example. It could be more complete by explaining pagination or return format, but it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 value by providing a concrete example and common user asks, which helps understand parameter usage beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Query' and resource 'raw individual Hyperliquid fills' are specific. The description clearly states what the tool does and distinguishes from siblings by focusing on raw fill records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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. It contrasts with aggregated or analytics tools, helping the agent decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/subsquid-labs/portal-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server