Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

SQD

REMOTE · PORTAL.SQD.DEV · SCANNED SEP 24

Query 130+ SQD Portal datasets across blockchains, including native Tron transactions and events.

Available components

remote · portal.sqd.dev 78
0 this week 78 Trust /100
Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →

Endpoint Security69
Transport & Reachability100
Schema Quality & AI Usability57
  • 55% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Partial
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 17519 tokens (~449/item across 39 items; 31 tools + 8 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management86
  • Stability check failed: schema churn in the 30 days we've observed: 0 tool removals, 8 breaking changes, 0 auth/transport breaks, 3 additions. See how to fix → Fail
Tool Coverage100
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 100% of tool parameters carry a description.Pass
  • Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • We read all 31 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
  • An AI judge read all 33 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a current MCP spec version (2026-07-28).Pass
Install

How do I install the SQD MCP server?

SQD is a hosted endpoint at https://portal.sqd.dev/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

remote · portal.sqd.dev

# add to Claude Code
claude mcp add --transport http subsquid-labs-portal-mcp-server 'https://portal.sqd.dev/mcp'
// .cursor/mcp.json
{
  "mcpServers": {
    "subsquid-labs-portal-mcp-server": {
      "url": "https://portal.sqd.dev/mcp"
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "subsquid-labs-portal-mcp-server": {
      "type": "http",
      "url": "https://portal.sqd.dev/mcp"
    }
  }
}
# ~/.codex/config.toml
[mcp_servers.subsquid-labs-portal-mcp-server]
url = "https://portal.sqd.dev/mcp"
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "subsquid-labs-portal-mcp-server": {
      "type": "remote",
      "url": "https://portal.sqd.dev/mcp",
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add subsquid-labs-portal-mcp-server --url 'https://portal.sqd.dev/mcp' --transport streamable-http
# ~/.hermes/config.yaml
mcp_servers:
  subsquid-labs-portal-mcp-server:
    url: "https://portal.sqd.dev/mcp"
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "subsquid-labs-portal-mcp-server": {
      "Transport": "http",
      "Url": "https://portal.sqd.dev/mcp"
    }
  }
}
# add to Vellum
assistant mcp add subsquid-labs-portal-mcp-server -t streamable-http -u 'https://portal.sqd.dev/mcp'
// mcp.json
{
  "mcpServers": {
    "subsquid-labs-portal-mcp-server": {
      "type": "http",
      "url": "https://portal.sqd.dev/mcp"
    }
  }
}

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 8 Sept 26 0
    • Resource “sqd-blockchain-activity-explorer” now points somewhere else: ui://sqd/activity-explorer.2739daedf676.html → ui://sqd/activity-explorer.7e6b85590c27.html security
    • The server rewrote its instructions, which are the text every model session reads security
    • Schema quality: 404 → 449 ▼ functional
    • Server version: 0.8.4 → 0.8.5 functional
    • New tool “portal_evm_query_traces” functional
    • New tool “portal_tron_query_logs” functional
    • New tool “portal_tron_query_transactions” functional
    • “portal_bitcoin_query_transactions” reworded the description of “limit” cosmetic
    • “portal_get_time_series” reworded the description of “duration” cosmetic
    • “portal_get_time_series” reworded the description of “metric” cosmetic
  • 2 Sept 26 +1
    • Resource “sqd-blockchain-activity-explorer” now points somewhere else: ui://sqd/activity-explorer.383ddd6e2c61.html → ui://sqd/activity-explorer.2739daedf676.html security
    • The server rewrote its instructions, which are the text every model session reads security
    • Tool “portal_bitcoin_get_analytics” rewrote its description, which is the text the model reads security
    • Tool “portal_bitcoin_query_transactions” rewrote its description, which is the text the model reads security
    • Tool “portal_evm_get_analytics” rewrote its description, which is the text the model reads security
    • Tool “portal_evm_get_contract_activity” rewrote its description, which is the text the model reads security
    • Tool “portal_evm_get_contract_deployment” rewrote its description, which is the text the model reads security
    • Tool “portal_evm_get_ohlc” rewrote its description, which is the text the model reads security
    • Tool “portal_evm_query_logs” rewrote its description, which is the text the model reads security
    • Tool “portal_evm_query_token_transfers” rewrote its description, which is the text the model reads security
    • Tool “portal_evm_query_transactions” rewrote its description, which is the text the model reads security
    • Tool “portal_get_recent_activity” rewrote its description, which is the text the model reads security
    • Tool “portal_get_time_series” rewrote its description, which is the text the model reads security
    • Tool “portal_get_wallet_summary” rewrote its description, which is the text the model reads security
    • Tool “portal_hyperliquid_get_analytics” rewrote its description, which is the text the model reads security
    • Tool “portal_hyperliquid_get_ohlc” rewrote its description, which is the text the model reads security
    • Tool “portal_hyperliquid_query_fills” rewrote its description, which is the text the model reads security
    • Tool “portal_solana_get_analytics” rewrote its description, which is the text the model reads security
    • Tool “portal_solana_query_instructions” rewrote its description, which is the text the model reads security
    • Tool “portal_solana_query_transactions” rewrote its description, which is the text the model reads security
    • Tool “portal_substrate_get_analytics” rewrote its description, which is the text the model reads security
    • Tool “portal_substrate_query_calls” rewrote its description, which is the text the model reads security
    • Tool “portal_substrate_query_events” rewrote its description, which is the text the model reads security
    • Schema quality: 456 → 404 ▲ functional
    • Schema quality: 44% → 55% ▲ functional
    • New resource “sqd-blockchain-activity-explorer-compat-1” functional
    • New resource “sqd-blockchain-activity-explorer-compat-2” functional
    • “portal_hyperliquid_get_ohlc” added an optional parameter “from_timestamp” cosmetic
    • “portal_hyperliquid_get_ohlc” added an optional parameter “to_timestamp” cosmetic
    • “portal_get_wallet_summary” reworded the description of “limit_per_type” cosmetic
    • “portal_hyperliquid_get_ohlc” reworded the description of “duration” cosmetic
    • “portal_hyperliquid_query_fills” reworded the description of “limit” cosmetic
  • 31 Aug 26 −2
    • Stability: pass → fail ▼ security
    • Resource “sqd-blockchain-activity-explorer” now points somewhere else: ui://sqd/activity-explorer.457443ca1623.html → ui://sqd/activity-explorer.383ddd6e2c61.html security
    • The server rewrote its instructions, which are the text every model session reads security
    • Tool “portal_bitcoin_get_analytics” rewrote its description, which is the text the model reads security
    • Tool “portal_bitcoin_query_transactions” rewrote its description, which is the text the model reads security
    • Tool “portal_debug_hyperliquid_query_replica_commands” rewrote its description, which is the text the model reads security
    • Tool “portal_evm_get_analytics” rewrote its description, which is the text the model reads security
    • Tool “portal_evm_get_contract_activity” rewrote its description, which is the text the model reads security
    • Tool “portal_evm_get_contract_deployment” rewrote its description, which is the text the model reads security
    • Tool “portal_evm_get_ohlc” rewrote its description, which is the text the model reads security
    • Tool “portal_evm_query_logs” rewrote its description, which is the text the model reads security
    • Tool “portal_evm_query_token_transfers” rewrote its description, which is the text the model reads security
    • Tool “portal_evm_query_transactions” rewrote its description, which is the text the model reads security
    • Tool “portal_get_recent_activity” rewrote its description, which is the text the model reads security
    • Tool “portal_get_time_series” rewrote its description, which is the text the model reads security
    • Tool “portal_get_wallet_summary” rewrote its description, which is the text the model reads security
    • Tool “portal_hyperliquid_get_analytics” rewrote its description, which is the text the model reads security
    • Tool “portal_hyperliquid_get_ohlc” rewrote its description, which is the text the model reads security
    • Tool “portal_hyperliquid_query_fills” rewrote its description, which is the text the model reads security
    • Tool “portal_solana_get_analytics” rewrote its description, which is the text the model reads security
    • Tool “portal_solana_query_instructions” rewrote its description, which is the text the model reads security
    • Tool “portal_solana_query_transactions” rewrote its description, which is the text the model reads security
    • Tool “portal_substrate_get_analytics” rewrote its description, which is the text the model reads security
    • Tool “portal_substrate_query_calls” rewrote its description, which is the text the model reads security
    • Tool “portal_substrate_query_events” rewrote its description, which is the text the model reads security
    • “portal_debug_hyperliquid_query_replica_commands” changed the type of “limit”: number → integer ▼ functional
    • “portal_evm_query_logs” changed the type of “limit”: number → integer ▼ functional
    • “portal_evm_query_transactions” changed the type of “limit”: number → integer ▼ functional
    • “portal_get_recent_activity” changed the type of “limit”: number → integer ▼ functional
    • “portal_get_wallet_summary” changed the type of “limit_per_type”: number → integer ▼ functional
    • “portal_solana_query_instructions” changed the type of “limit”: number → integer ▼ functional
    • “portal_substrate_query_calls” changed the type of “limit”: number → integer ▼ functional
    • “portal_substrate_query_events” changed the type of “limit”: number → integer ▼ functional
    • Server version: 0.8.3 → 0.8.4 functional
    • “portal_bitcoin_query_transactions” reworded the description of “limit” cosmetic
    • “portal_debug_hyperliquid_query_replica_commands” reworded the description of “limit” cosmetic
    • “portal_evm_query_logs” reworded the description of “limit” cosmetic
    • “portal_evm_query_transactions” reworded the description of “limit” cosmetic
    • “portal_get_recent_activity” reworded the description of “limit” cosmetic
    • “portal_get_wallet_summary” reworded the description of “limit_per_type” cosmetic
    • “portal_hyperliquid_query_fills” reworded the description of “limit” cosmetic
    • “portal_solana_query_instructions” reworded the description of “limit” cosmetic
    • “portal_solana_query_transactions” reworded the description of “limit” cosmetic
    • “portal_substrate_query_calls” reworded the description of “limit” cosmetic
    • “portal_substrate_query_events” reworded the description of “limit” cosmetic
  • 30 Aug 26 +3
    • The server rewrote its instructions, which are the text every model session reads security
    • Schema quality: 0% → 44% ▲ functional
    • The server now declares the “completions” capability functional
    • The server now declares the “prompts” capability functional
    • First check of Capabilities: pass functional
    • New prompt “investigate-contract” functional
    • New prompt “investigate-market” functional
    • New prompt “investigate-wallet” functional
    • New resource “investigation-guide” functional
    • New resource “sqd-blockchain-activity-explorer” functional
    • Server version: 0.8.2 → 0.8.3 functional
  • 28 Aug 26 +7
    • Authorization: unverified → partial ▲ security
    • The server rewrote its instructions, which are the text every model session reads security
    • Tool “portal_bitcoin_get_analytics” now declares an output schema ▲ functional
    • Tool “portal_bitcoin_query_transactions” now declares an output schema ▲ functional
    • Tool “portal_debug_hyperliquid_query_replica_commands” now declares an output schema ▲ functional
    • Tool “portal_debug_query_blocks” now declares an output schema ▲ functional
    • Tool “portal_debug_resolve_time_to_block” now declares an output schema ▲ functional
    • Tool “portal_evm_get_analytics” now declares an output schema ▲ functional
    • Tool “portal_evm_get_contract_activity” now declares an output schema ▲ functional
    • Tool “portal_evm_get_contract_deployment” now declares an output schema ▲ functional
    • Tool “portal_evm_get_ohlc” now declares an output schema ▲ functional
    • Tool “portal_evm_query_logs” now declares an output schema ▲ functional
    • Tool “portal_evm_query_token_transfers” now declares an output schema ▲ functional
    • Tool “portal_evm_query_transactions” now declares an output schema ▲ functional
    • Tool “portal_get_head” now declares an output schema ▲ functional
    • Tool “portal_get_network_info” now declares an output schema ▲ functional
    • Tool “portal_get_recent_activity” now declares an output schema ▲ functional
    • Tool “portal_get_time_series” now declares an output schema ▲ functional
    • Tool “portal_get_wallet_summary” now declares an output schema ▲ functional
    • Tool “portal_hyperliquid_get_analytics” now declares an output schema ▲ functional
    • Tool “portal_hyperliquid_get_ohlc” now declares an output schema ▲ functional
    • Tool “portal_hyperliquid_query_fills” now declares an output schema ▲ functional
    • Tool “portal_list_networks” now declares an output schema ▲ functional
    • Tool “portal_resolve_entity” now declares an output schema ▲ functional
    • Tool “portal_solana_get_analytics” now declares an output schema ▲ functional
    • Tool “portal_solana_query_instructions” now declares an output schema ▲ functional
    • Tool “portal_solana_query_transactions” now declares an output schema ▲ functional
    • Tool “portal_substrate_get_analytics” now declares an output schema ▲ functional
    • Tool “portal_substrate_query_calls” now declares an output schema ▲ functional
    • Tool “portal_substrate_query_events” now declares an output schema ▲ functional
    • First check of Tool coverage: 100 functional
    • MCP protocol: Implements a current MCP spec version (2026-07-28). functional
    • MCP protocol version: 2025-11-25 → 2026-07-28 functional
    • Server version: 0.8.1 → 0.8.2 functional
    • Server version: 0.8.0 → 0.8.1 functional
    • Server version: 0.7.9 → 0.8.0 functional
    • “portal_list_networks” added an optional parameter “cursor” cosmetic
    • “portal_evm_query_logs” added an optional parameter “max_scan_blocks” cosmetic
    • “portal_evm_query_logs” reworded the description of “timeframe” cosmetic
    • “portal_evm_query_transactions” reworded the description of “timeframe” cosmetic
    • Tool “portal_bitcoin_get_analytics” changed its title: Analyze Bitcoin activity cosmetic
    • Tool “portal_bitcoin_query_transactions” changed its title: Find Bitcoin transactions cosmetic
    • Tool “portal_debug_hyperliquid_query_replica_commands” changed its title: Inspect Hyperliquid command records cosmetic
    • Tool “portal_debug_query_blocks” changed its title: Inspect raw blocks cosmetic
    • Tool “portal_debug_resolve_time_to_block” changed its title: Match a time to a block cosmetic
    • Tool “portal_evm_get_analytics” changed its title: Analyze Ethereum and Base activity cosmetic
    • Tool “portal_evm_get_contract_activity” changed its title: Review smart contract activity cosmetic
    • Tool “portal_evm_get_contract_deployment” changed its title: Find a contract deployment cosmetic
    • Tool “portal_evm_get_ohlc” changed its title: Chart token price history cosmetic
    • Tool “portal_evm_query_logs” changed its title: Find smart contract events cosmetic
    • Tool “portal_evm_query_token_transfers” changed its title: Find token transfers cosmetic
    • Tool “portal_evm_query_transactions” changed its title: Find Ethereum and Base transactions cosmetic
    • Tool “portal_get_head” changed its title: Get the latest block cosmetic
    • Tool “portal_get_network_info” changed its title: Check network status cosmetic
    • Tool “portal_get_recent_activity” changed its title: View recent blockchain activity cosmetic
    • Tool “portal_get_time_series” changed its title: Chart blockchain activity cosmetic
    • Tool “portal_get_wallet_summary” changed its title: Review wallet activity cosmetic
    • Tool “portal_hyperliquid_get_analytics” changed its title: Analyze Hyperliquid trading cosmetic
    • Tool “portal_hyperliquid_get_ohlc” changed its title: Chart Hyperliquid prices cosmetic
    • Tool “portal_hyperliquid_query_fills” changed its title: Find Hyperliquid trades cosmetic
    • Tool “portal_list_networks” changed its title: Find blockchain networks cosmetic
    • Tool “portal_resolve_entity” changed its title: Find a token or contract cosmetic
    • Tool “portal_solana_get_analytics” changed its title: Analyze Solana activity cosmetic
    • Tool “portal_solana_query_instructions” changed its title: Find Solana program activity cosmetic
    • Tool “portal_solana_query_transactions” changed its title: Find Solana transactions cosmetic
    • Tool “portal_substrate_get_analytics” changed its title: Analyze Polkadot activity cosmetic
    • Tool “portal_substrate_query_calls” changed its title: Find Polkadot calls cosmetic
    • Tool “portal_substrate_query_events” changed its title: Find Polkadot events cosmetic
  • 26 Aug 26 69
    • We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
  • 25 Aug 26 0
    • Stability: 0.97 → pass security
  • 11 Aug 26 0
    • We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 24 Sept 2026 · Probed https://portal.sqd.dev/mcp

TLS valid

Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .

Subject Issuer Valid from Valid until Key Signature Serial
CN=sqd.dev CN=WE1,O=Google Trust Services,C=US 8 Sept 2026 7 Dec 2026 ECDSA 256 ECDSA-SHA256 fd9170d4196a777313bdef361ea10f84
SANs: sqd.dev, *.sqd.dev, *.docs.sqd.dev
CN=WE1,O=Google Trust Services,C=US (CA) CN=GTS Root R4,O=Google Trust Services LLC,C=US 13 Dec 2023 20 Feb 2029 ECDSA 256 ECDSA-SHA384 7ff31977972c224a76155d13b6d685e3
CN=GTS Root R4,O=Google Trust Services LLC,C=US (CA) CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE 15 Nov 2023 28 Jan 2028 ECDSA 384 SHA256-RSA 7fe530bf331343bedd821610493d8a1b

Background: What to check on a remote MCP endpoint →

DNSSEC insecure

Validation of portal.sqd.dev. — Not signed

Zone DS Keys Algorithms Outcome
. trust_anchor 20326, 38696 8, 8 Verified
dev. present 60074 8 Verified
sqd.dev. absent Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation
Authentication No authorisation required

The endpoint answered without asking for a token. Anyone who knows the URL can reach it.

Result No authorisation required
HTTP status 200
Header Value
strict-transport-security max-age=31536000; includeSubDomains

Background: How OAuth 2.1 works in the 2026 MCP spec →

Transports 2 probes
Transport URL Outcome Status Location
streamable-http https://portal.sqd.dev/mcp Verified 200
http (plaintext) http://portal.sqd.dev/mcp Inconclusive 405
MCP tools · 31 exposed · ~17,229 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
portal_bitcoin_get_analytics ~356

Get the big picture for Bitcoin block, fee, and address activity over a recent or explicit window. COMMON USER ASKS: - Bitcoin network snapshot FIRST CHOICE FOR: - the big picture for Bitcoin right now WHEN TO USE: - You want the big picture for Bitcoin right now. - You want a network-level Bitcoin snapshot. - You care about block cadence, fees, SegWit/Taproot adoption, or activity metrics. DON'T USE: - You need raw transactions rather than network analytics. EXAMPLES: - Bitcoin network snapshot: {"network":"bitcoin-mainnet","timeframe":"1h"}

NameTypeReqDescription
from_blocknumber–Starting block number (use this OR timeframe)
from_timestamp––Starting timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "6h ago".
include_address_activityboolean–Include unique address count and output value (requires extra queries, slower)
modestring–Execution depth. Defaults to complete requested-window analysis; the optional fast value is only for explicitly bounded previews.
networkstring–Network name (default: bitcoin-mainnet)
response_formatstring–Response format: 'summary' (high-level metrics only), 'compact' (core sections, lighter payload), 'full' (complete analytics).
timeframestring–Time range: '1h' (~6 blocks), '6h' (~36 blocks), '24h' (~144 blocks). Default: '1h'
to_blocknumber–Ending block number
to_timestamp––Ending timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "now".
NameTypeReqDescription
_app––SQD Explorer identity and host-render state.
_coverage––Window and result completeness.
_evidence––Replayable arguments, digest, row count, and receipt.
_execution––Bounded execution and scan details.
_freshness––Freshness and finality.
_llm––Hints to locate the primary evidence.
_meta––Network, block range, timing, and row counts.
_noticestring–Limitation or truncation notice.
_noticesarray–Limitation or truncation notices.
_ordering––Ordering guarantees.
_pagination––Pagination state and next_cursor.
_serverobject–SQD server name, exact version, and git commit.
_summarystring–Human-readable summary.
_tool_contract––Tool identity, intent, and chain families.
_ui––Chart, table, and follow-up presentation metadata.
answerstring–Answer grounded in the returned data.
display––Labels for presenting the result.
errorobject–Structured failure details.
investigation––Evidence paths, pivots, and limitations.
itemsarray–Primary rows for list results.
next_steps––Safe follow-up actions and continuation guidance.
pipes_handoff––SQD Pipes guidance for custom data needs.
value––Primary scalar result.

No examples provided.

portal_bitcoin_query_transactions ~411

Query raw Bitcoin transactions and optionally attach inputs and outputs inline. COMMON USER ASKS: - Recent Bitcoin transactions - Attach inputs and outputs WHEN TO USE: - You need raw Bitcoin transaction records. - You want the UTXO envelope without switching to separate input/output tools. DON'T USE: - You only need a quick wallet or network summary. EXAMPLES: - Recent Bitcoin transactions: {"network":"bitcoin-mainnet","timeframe":"1h","limit":20} - Attach inputs and outputs: {"network":"bitcoin-mainnet","timeframe":"1h","include_inputs":true,"include_outputs":true,"limit":10}

NameTypeReqDescription
cursorstring–Continuation cursor from a previous response
finalized_onlyboolean–Only query finalized blocks
from_blocknumber–Starting block number
from_timestamp––Starting timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "1h ago".
include_inputsboolean–Attach transaction inputs inline
include_outputsboolean–Attach transaction outputs inline
limitinteger–Max transactions to return (default: 20, max: 25). With include_inputs or include_outputs and response_format "full", a page near the maximum can exceed the 50,000-byte response budget; the response_…
networkstring–Network name (default: bitcoin-mainnet). Optional when continuing with cursor.
response_formatstring–Response format: defaults to 'compact' for chat-friendly output. Compact mode keeps inline inputs and outputs in a smaller shape when requested.
timeframestring–Time range (e.g., '1h', '24h'). Alternative to from_block/to_block.
to_blocknumber–Ending block number
to_timestamp––Ending timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "now".
NameTypeReqDescription
_app––SQD Explorer identity and host-render state.
_coverage––Window and result completeness.
_evidence––Replayable arguments, digest, row count, and receipt.
_execution––Bounded execution and scan details.
_freshness––Freshness and finality.
_llm––Hints to locate the primary evidence.
_meta––Network, block range, timing, and row counts.
_noticestring–Limitation or truncation notice.
_noticesarray–Limitation or truncation notices.
_ordering––Ordering guarantees.
_pagination––Pagination state and next_cursor.
_serverobject–SQD server name, exact version, and git commit.
_summarystring–Human-readable summary.
_tool_contract––Tool identity, intent, and chain families.
_ui––Chart, table, and follow-up presentation metadata.
answerstring–Answer grounded in the returned data.
display––Labels for presenting the result.
errorobject–Structured failure details.
investigation––Evidence paths, pivots, and limitations.
itemsarray–Primary rows for list results.
next_steps––Safe follow-up actions and continuation guidance.
pipes_handoff––SQD Pipes guidance for custom data needs.
value––Primary scalar result.

No examples provided.

portal_debug_hyperliquid_query_replica_commands ~382

ADVANCED: Query Hyperliquid replica-command actions such as orders, cancels, and leverage updates. COMMON USER ASKS: - Recent order action WHEN TO USE: - You are debugging Hyperliquid replica-command records. - You need raw order-action events instead of fills or analytics. DON'T USE: - You only need public trading activity; fills and analytics are usually the better fit. EXAMPLES: - Recent order action: {"network":"hyperliquid-replica-cmds","timeframe":"5m","limit":1}

NameTypeReqDescription
action_typearray–Action types to filter
cursorstring–Continuation cursor from a previous response
finalized_onlyboolean–Only query finalized blocks
from_blocknumber–Starting block number (use this OR timeframe)
from_timestamp––Starting timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "1h ago".
limitinteger–Max actions to return (1). Replica command payloads can contain large batches, so this exact one-record cursor page is the verified safe response budget.
networkstring–Network name (default: 'hyperliquid-replica-cmds'). Optional when continuing with cursor.
statusstring–Filter by action status
timeframestring–Time range (e.g., '1h', '24h'). Alternative to from_block/to_block.
to_blocknumber–Ending block number
to_timestamp––Ending timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "now".
userarray–User wallet addresses (0x-prefixed, lowercase)
vault_addressarray–Vault addresses (0x-prefixed, lowercase)
NameTypeReqDescription
_app––SQD Explorer identity and host-render state.
_coverage––Window and result completeness.
_evidence––Replayable arguments, digest, row count, and receipt.
_execution––Bounded execution and scan details.
_freshness––Freshness and finality.
_llm––Hints to locate the primary evidence.
_meta––Network, block range, timing, and row counts.
_noticestring–Limitation or truncation notice.
_noticesarray–Limitation or truncation notices.
_ordering––Ordering guarantees.
_pagination––Pagination state and next_cursor.
_serverobject–SQD server name, exact version, and git commit.
_summarystring–Human-readable summary.
_tool_contract––Tool identity, intent, and chain families.
_ui––Chart, table, and follow-up presentation metadata.
answerstring–Answer grounded in the returned data.
display––Labels for presenting the result.
errorobject–Structured failure details.
investigation––Evidence paths, pivots, and limitations.
itemsarray–Primary rows for list results.
next_steps––Safe follow-up actions and continuation guidance.
pipes_handoff––SQD Pipes guidance for custom data needs.
value––Primary scalar result.

No examples provided.

portal_debug_query_blocks ~372

ADVANCED: Query raw block records directly for EVM, Solana, or Bitcoin. COMMON USER ASKS: - Recent Base blocks WHEN TO USE: - You are debugging Portal coverage or block-level fields. - You need raw block records instead of transactions, logs, or summaries. DON'T USE: - You are answering a normal end-user question; prefer recent activity, time series, or raw transaction tools first. EXAMPLES: - Recent Base blocks: {"network":"base-mainnet","timeframe":"1h","limit":5}

NameTypeReqDescription
cursorstring–Continuation cursor from a previous response
field_presetstring–Field preset for EVM datasets: 'minimal' (number+timestamp+gas), 'standard' (+hash+miner+size), 'full' (all block fields). Ignored for Solana/Bitcoin.
finalized_onlyboolean–Only query finalized blocks
from_blocknumber–Starting block number (use this OR timeframe)
from_timestamp––Starting timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "1h ago".
include_l2_fieldsboolean–Include L2-specific fields (auto-detected for L2 chains)
limitnumber–Max blocks to return (default: 20). Note: Lower default for MCP to reduce context usage.
networkstring–Network name or alias. Optional when continuing with cursor.
timeframestring–Time range (e.g., '1h', '24h'). Alternative to from_block/to_block.
to_blocknumber–Ending block number
to_timestamp––Ending timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "now".
NameTypeReqDescription
_app––SQD Explorer identity and host-render state.
_coverage––Window and result completeness.
_evidence––Replayable arguments, digest, row count, and receipt.
_execution––Bounded execution and scan details.
_freshness––Freshness and finality.
_llm––Hints to locate the primary evidence.
_meta––Network, block range, timing, and row counts.
_noticestring–Limitation or truncation notice.
_noticesarray–Limitation or truncation notices.
_ordering––Ordering guarantees.
_pagination––Pagination state and next_cursor.
_serverobject–SQD server name, exact version, and git commit.
_summarystring–Human-readable summary.
_tool_contract––Tool identity, intent, and chain families.
_ui––Chart, table, and follow-up presentation metadata.
answerstring–Answer grounded in the returned data.
display––Labels for presenting the result.
errorobject–Structured failure details.
investigation––Evidence paths, pivots, and limitations.
itemsarray–Primary rows for list results.
next_steps––Safe follow-up actions and continuation guidance.
pipes_handoff––SQD Pipes guidance for custom data needs.
value––Primary scalar result.

No examples provided.

portal_debug_resolve_time_to_block ~193

ADVANCED: Resolve a timestamp to the nearest indexed block or slot. COMMON USER ASKS: - Resolve one hour ago on Base - Resolve an older time on Polkadot WHEN TO USE: - You are debugging timestamp windows or building a manual block-range query. - You want to inspect exact versus estimated timestamp-to-block resolution. DON'T USE: - You just want to query by time; most public tools already accept natural timestamps directly. EXAMPLES: - Resolve one hour ago on Base: {"network":"base-mainnet","timestamp":"1h ago"} - Resolve an older time on Polkadot: {"network":"polkadot","timestamp":"2026-04-08T12:00:00Z"}

NameTypeReqDescription
networkstringyesNetwork name or alias
timestamp–yesUnix seconds, Unix milliseconds, ISO datetime, or relative input like "1h ago"
NameTypeReqDescription
_app––SQD Explorer identity and host-render state.
_coverage––Window and result completeness.
_evidence––Replayable arguments, digest, row count, and receipt.
_execution––Bounded execution and scan details.
_freshness––Freshness and finality.
_llm––Hints to locate the primary evidence.
_meta––Network, block range, timing, and row counts.
_noticestring–Limitation or truncation notice.
_noticesarray–Limitation or truncation notices.
_ordering––Ordering guarantees.
_pagination––Pagination state and next_cursor.
_serverobject–SQD server name, exact version, and git commit.
_summarystring–Human-readable summary.
_tool_contract––Tool identity, intent, and chain families.
_ui––Chart, table, and follow-up presentation metadata.
answerstring–Answer grounded in the returned data.
display––Labels for presenting the result.
errorobject–Structured failure details.
investigation––Evidence paths, pivots, and limitations.
itemsarray–Primary rows for list results.
next_steps––Safe follow-up actions and continuation guidance.
pipes_handoff––SQD Pipes guidance for custom data needs.
value––Primary scalar result.

No examples provided.

portal_evm_get_analytics ~363

Get the big picture for network-wide EVM activity with ranked contracts and compact overview metrics. COMMON USER ASKS: - Top contracts on Base FIRST CHOICE FOR: - the big picture for activity on an EVM network like Base or Optimism WHEN TO USE: - You want the big picture for activity on an EVM network. - You want the most active contracts on an EVM network. - You want an analytics-style network overview instead of a raw record list. DON'T USE: - You need chart buckets over time rather than ranked entities. EXAMPLES: - Top contracts on Base: {"network":"base-mainnet","timeframe":"1h","limit":10}

NameTypeReqDescription
cursorstring–Continuation cursor from a previous response
from_timestamp––Starting timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "1h ago".
include_detailsboolean–Include sample transaction hashes for each contract
limitnumber–Number of top contracts to return (default: 10, max: 100)
modestring–Execution depth. Defaults to complete requested-window analysis; the optional fast value is only for explicitly bounded previews.
networkstring–Network name (supports short names: 'ethereum', 'polygon', 'base', etc.). Optional when continuing with cursor.
num_blocksnumber–Number of recent blocks to analyze when timeframe is omitted (default: 50, max: 10000)
timeframestring–Optional natural time window like '1h' or '24h'
to_timestamp––Ending timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "now".
NameTypeReqDescription
_app––SQD Explorer identity and host-render state.
_coverage––Window and result completeness.
_evidence––Replayable arguments, digest, row count, and receipt.
_execution––Bounded execution and scan details.
_freshness––Freshness and finality.
_llm––Hints to locate the primary evidence.
_meta––Network, block range, timing, and row counts.
_noticestring–Limitation or truncation notice.
_noticesarray–Limitation or truncation notices.
_ordering––Ordering guarantees.
_pagination––Pagination state and next_cursor.
_serverobject–SQD server name, exact version, and git commit.
_summarystring–Human-readable summary.
_tool_contract––Tool identity, intent, and chain families.
_ui––Chart, table, and follow-up presentation metadata.
answerstring–Answer grounded in the returned data.
display––Labels for presenting the result.
errorobject–Structured failure details.
investigation––Evidence paths, pivots, and limitations.
itemsarray–Primary rows for list results.
next_steps––Safe follow-up actions and continuation guidance.
pipes_handoff––SQD Pipes guidance for custom data needs.
value––Primary scalar result.

No examples provided.

portal_evm_get_contract_activity ~322

Summarize what one specific contract has been doing lately, including recent interactions, unique callers, and optional event activity. COMMON USER ASKS: - Contract activity snapshot FIRST CHOICE FOR: - what one specific contract has been doing lately on an EVM network WHEN TO USE: - You want to ask "what has this contract been doing?" and get a contract-level answer. - You want a contract-centric activity summary instead of raw records. - You need top callers and interaction volume for one contract. DON'T USE: - You need the underlying raw logs or transactions. - You want general recent network activity without naming one contract. EXAMPLES: - Contract activity snapshot: {"network":"base-mainnet","contract_address":"0xabc...","timeframe":"24h"}

NameTypeReqDescription
contract_addressstringyesContract address to analyze
from_timestamp––Starting timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "1h ago".
include_eventsboolean–Include event log summary
modestring–Execution depth. Defaults to complete requested-window analysis; the optional fast value is only for explicitly bounded previews.
networkstringyesNetwork name or alias
timeframestring–Analysis period as timeframe or block count. Examples: '1h', '24h', '7d', '3d', '1000'.
to_timestamp––Ending timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "now".
NameTypeReqDescription
_app––SQD Explorer identity and host-render state.
_coverage––Window and result completeness.
_evidence––Replayable arguments, digest, row count, and receipt.
_execution––Bounded execution and scan details.
_freshness––Freshness and finality.
_llm––Hints to locate the primary evidence.
_meta––Network, block range, timing, and row counts.
_noticestring–Limitation or truncation notice.
_noticesarray–Limitation or truncation notices.
_ordering––Ordering guarantees.
_pagination––Pagination state and next_cursor.
_serverobject–SQD server name, exact version, and git commit.
_summarystring–Human-readable summary.
_tool_contract––Tool identity, intent, and chain families.
_ui––Chart, table, and follow-up presentation metadata.
answerstring–Answer grounded in the returned data.
display––Labels for presenting the result.
errorobject–Structured failure details.
investigation––Evidence paths, pivots, and limitations.
itemsarray–Primary rows for list results.
next_steps––Safe follow-up actions and continuation guidance.
pipes_handoff––SQD Pipes guidance for custom data needs.
value––Primary scalar result.

No examples provided.

portal_evm_get_contract_deployment ~573

Locate the create trace and parent transaction that deployed a specific EVM contract address within a bounded window. COMMON USER ASKS: - Find BAYC deployment - Find recent deployment - Find deployment from known range FIRST CHOICE FOR: - who deployed this EVM contract - when was this contract deployed - what deployment transaction created this contract WHEN TO USE: - You need the deployer, deployment block, deployment timestamp, or deployment transaction for an EVM contract. - You can provide a starting block/time window, a contract address, or a supported well-known contract alias such as BAYC/Bored Apes. - You want a deployment lookup instead of general contract activity. DON'T USE: - You need all activity for a contract after deployment. - The contract is old and no block/time hint is available; provide from_block or from_timestamp first. EXAMPLES: - Find BAYC deployment: {"network":"ethereum-mainnet","contract":"bored apes","from_block":12000000,"to_block":13000000,"scan_order":"earliest"} - Find recent deployment: {"network":"base-mainnet","contract_address":"0xabc...","search_depth_blocks":100000} - Find deployment from known range: {"network":"ethereum-mainnet","contract_address":"0xabc...","from_block":17000000,"to_block":17100000,"scan_order":"earliest"}

NameTypeReqDescription
contractstring–Contract address or a supported well-known alias/name, e.g. "bayc" or "bored apes" on Ethereum.
contract_addressstring–Contract address whose deployment transaction should be located.
from_blocknumber–Optional starting block. Provide this for older contracts when the deployment is not recent.
from_timestamp––Starting timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "7d ago".
max_scan_blocksnumber–Safety cap for historical deployment scans. Default: scan the requested window up to 1,000,000 blocks.
networkstringyesEVM network name or alias, e.g. base, ethereum, arbitrum.
scan_orderstring–Scan latest first for recent deployments, or earliest first when you provide a historical from_block.
search_depth_blocksnumber–When no explicit range is given, search this many recent blocks backward from the indexed head.
timeframestring–Optional recent time window to search, e.g. "24h" or "7d".
to_blocknumber–Optional ending block. Defaults to the indexed head.
to_timestamp––Ending timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "now".
NameTypeReqDescription
_app––SQD Explorer identity and host-render state.
_coverage––Window and result completeness.
_evidence––Replayable arguments, digest, row count, and receipt.
_execution––Bounded execution and scan details.
_freshness––Freshness and finality.
_llm––Hints to locate the primary evidence.
_meta––Network, block range, timing, and row counts.
_noticestring–Limitation or truncation notice.
_noticesarray–Limitation or truncation notices.
_ordering––Ordering guarantees.
_pagination––Pagination state and next_cursor.
_serverobject–SQD server name, exact version, and git commit.
_summarystring–Human-readable summary.
_tool_contract––Tool identity, intent, and chain families.
_ui––Chart, table, and follow-up presentation metadata.
answerstring–Answer grounded in the returned data.
display––Labels for presenting the result.
errorobject–Structured failure details.
investigation––Evidence paths, pivots, and limitations.
itemsarray–Primary rows for list results.
next_steps––Safe follow-up actions and continuation guidance.
pipes_handoff––SQD Pipes guidance for custom data needs.
value––Primary scalar result.

No examples provided.

portal_evm_get_ohlc ~989

Build chart-ready EVM OHLC candles plus a recent trade tape from supported DEX event sources, including Uniswap v2-style swaps, Uniswap v3/v4, and Aerodrome Slipstream. COMMON USER ASKS: - Base Uniswap v2-style swap candles - Base Uniswap candles - Base Uniswap v4 candles WHEN TO USE: - You need OHLC candles for supported EVM event-derived price sources. - You want a candle chart and recent trades instead of scalar time-series buckets. - You want a Dexscreener-style pool chart with hover-ready candle metadata and a trade tape. DON'T USE: - You only need counts or scalar metrics over time. - You want a simple activity chart for a network rather than pool candles. EXAMPLES: - Base Uniswap v2-style swap candles: {"network":"base-mainnet","source":"uniswap_v2_swap","pool_address":"0x<pool-address>","duration":"1h","interval":"5m","price_in":"auto","include_recent_trades":true} - Base Uniswap candles: {"network":"base-mainnet","source":"uniswap_v3_swap","pool_address":"0x<pool-address>","duration":"1h","interval":"5m","price_in":"auto"} - Base Uniswap v4 candles: {"network":"base-mainnet","source":"uniswap_v4_swap","pool_id":"0x<pool-id>","duration":"1h","interval":"5m","price_in":"auto","include_recent_trades":true} - Base Aerodrome Slipstream candles: {"network":"base-mainnet","source":"aerodrome_slipstream_swap","pool_address":"0x<pool-address>","duration":"1h","interval":"5m","price_in":"token1"}

NameTypeReqDescription
base_tokenstring–Legacy orientation input. Prefer price_in instead.
currency0_addressstring–Optional Uniswap v4 currency0 address. Use with currency1_address, fee, and tick_spacing to derive pool_id factually.
currency1_addressstring–Optional Uniswap v4 currency1 address. Use with currency0_address, fee, and tick_spacing to derive pool_id factually.
cursorstring–Continuation cursor from a previous candle page
durationstring–How much recent history to cover. Accepts compact durations like "1h" or natural phrases like "past 30 minutes".
feeinteger–Optional Uniswap v4 LP fee in hundredths of a bip, e.g. 3000 for 0.30%.
hooks_addressstring–Optional Uniswap v4 hooks contract address. Defaults to the zero address when omitted.
include_recent_tradesboolean–Include a recent trade tape for swap-derived sources when factual per-trade amounts are available.
intervalstring–Candle interval. auto uses chart-friendly defaults like 1h→5m and 24h→1h.
modestring–Execution depth. Defaults to complete requested-window analysis; the optional fast value is only for explicitly bounded previews.
networkstring–EVM network name (default: base-mainnet)
pool_addressstring–Pool/pair contract address for address-keyed sources like Uniswap v3, Slipstream, or Sync-derived CPMM pools.
pool_idstring–Uniswap v4 pool id (bytes32). Optional when you provide the full v4 pool key instead.
pool_manager_addressstring–Uniswap v4 PoolManager address. Optional on networks with a built-in official Uniswap deployment mapping.
price_instring–Choose which token the displayed price should be expressed in. auto picks the more human-readable quote side.
recent_trades_limitinteger–Maximum number of recent trades to return in the trade tape.
sourcestring–Which event source to build candles from. Prefer swap-derived sources for factual trade prices and volumes. Uniswap v4 uses PoolManager Swap events filtered by pool_id, not a per-pool contract addres…
tick_spacinginteger–Optional Uniswap v4 tick spacing. Required with the rest of the pool key when deriving pool_id.
token0_addressstring–Optional token0 address to infer known decimals
token0_decimalsnumber–Optional token0 decimals for human-readable prices
token0_symbolstring–Optional token0 symbol label for summaries
token1_addressstring–Optional token1 address to infer known decimals
token1_decimalsnumber–Optional token1 decimals for human-readable prices
token1_symbolstring–Optional token1 symbol label for summaries
NameTypeReqDescription
_app––SQD Explorer identity and host-render state.
_coverage––Window and result completeness.
_evidence––Replayable arguments, digest, row count, and receipt.
_execution––Bounded execution and scan details.
_freshness––Freshness and finality.
_llm––Hints to locate the primary evidence.
_meta––Network, block range, timing, and row counts.
_noticestring–Limitation or truncation notice.
_noticesarray–Limitation or truncation notices.
_ordering––Ordering guarantees.
_pagination––Pagination state and next_cursor.
_serverobject–SQD server name, exact version, and git commit.
_summarystring–Human-readable summary.
_tool_contract––Tool identity, intent, and chain families.
_ui––Chart, table, and follow-up presentation metadata.
answerstring–Answer grounded in the returned data.
display––Labels for presenting the result.
errorobject–Structured failure details.
investigation––Evidence paths, pivots, and limitations.
itemsarray–Primary rows for list results.
next_steps––Safe follow-up actions and continuation guidance.
pipes_handoff––SQD Pipes guidance for custom data needs.
value––Primary scalar result.

No examples provided.

portal_evm_query_logs ~1,225

Query raw EVM logs with address/topic filters, common event aliases, earliest/latest scanning, and optional inline decoding. COMMON USER ASKS: - Recent USDC Transfer logs - First recent USDC Transfer log - Latest ERC721/pass mint ID and tx hash FIRST CHOICE FOR: - NFT or ERC721 mint lookups such as latest pass minted, token ID, and mint transaction hash - contract event questions where the user needs exact event evidence rather than wallet or transaction summaries WHEN TO USE: - You need event logs filtered by contract or topic signature. - You want decoded log hints while still keeping the raw log shape available. - You want the first or last matching event in a bounded block/time window. - You want common event names such as transfer, approval, swap, mint, or burn instead of remembering topic0 hashes. - You need the latest ERC721/pass mint in a bounded deployment/recent window: filter Transfer events with topic1 as the zero address, use scan_order=latest, limit=1, and decode=true to expose decoded_log.decoded.token_id plus transaction_hash. DON'T USE: - You only want token transfers, which are easier with the token-transfer tool. EXAMPLES: - Recent USDC Transfer logs: {"network":"base-mainnet","timeframe":"1h","token_symbols":["USDC"],"event":"transfer","limit":20} - First recent USDC Transfer log: {"network":"base-mainnet","timeframe":"1h","token_symbols":["USDC"],"event":"transfer","scan_order":"earliest","limit":1} - Latest ERC721/pass mint ID and tx hash: {"network":"base-mainnet","from_block":46020000,"to_block":46100000,"addresses":["0xE4E70FdF2Fc1147a7f35c4c5de88E6BeA63eeAfA"],"event":"transfer","topic1":["0x0000000000000000000000000000000000000000000000000000000000000000"],"scan_order":"latest","decode":true,"include_transaction":true,"limit":1} - Decode logs inline: {"network":"ethereum-mainnet","timeframe":"1h","topic0":["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"],"decode":true,"limit":10}

NameTypeReqDescription
addressesarray–Contract addresses to filter (e.g., ['0xUSDC...', '0xDAI...']). IMPORTANT: Always include this or topics for fast queries.
cursorstring–Continuation cursor from a previous response
decodeboolean–Decode known log signatures inline when topics/data are available
event––Common event alias or topic0 hash. Examples: "transfer", "approval", "swap", "sync", "deposit", "withdrawal". Merges with topic0.
field_presetstring–Field preset: 'minimal' (address+topic0+block, ~80% smaller), 'standard' (all topics+timestamp), 'full' (includes raw data hex, largest). Use 'minimal' to reduce context usage.
finalized_onlyboolean–Only query finalized blocks
from_blocknumber–Starting block number (use this OR timeframe)
from_timestamp––Starting timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "1h ago".
include_transactionboolean–Include parent transaction data
include_transaction_logsboolean–Include all logs from parent transactions
include_transaction_tracesboolean–Include traces for parent transactions
limitinteger–Max logs to return (default: 20, max: 25). This verified ceiling keeps pages within MCP client budgets.
max_scan_blocksinteger–Maximum blocks to inspect for bounded earliest/latest scans. Sparse latest searches default to 25,000 blocks to stay within MCP request timeouts; raise only when deeper coverage is worth the added la…
max_token_symbol_matchesnumber–Maximum token-list matches to include per token symbol. Use addresses for deterministic single-contract filters.
networkstring–Network name or alias. Optional when continuing with cursor.
response_formatstring–Response format: defaults to 'compact' for chat-friendly output, or stays 'full' when inline transaction context is requested. Use 'summary' for counting or categorizing.
scan_orderstring–Which side of the block window to scan first. Use earliest for first-event questions.
timeframestring–Natural time range such as '5m', '1h', '24h', '7d', or 'past 30 minutes'. Alternative to from_block/to_block.
to_blocknumber–Ending block number. RECOMMENDED: <10k blocks for fast (<1s) responses. Larger ranges may be slow or timeout.
to_timestamp––Ending timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "now".
token_symbolsarray–Token symbols to resolve via open token-list data and merge into addresses, e.g. ["USDC"].
topic0array–Event signatures (topic0). E.g., Transfer = 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef
topic1array–Topic1 filter (often: from address in Transfer, indexed parameter 1)
topic2array–Topic2 filter (often: to address in Transfer, indexed parameter 2)
topic3array–Topic3 filter (indexed parameter 3, chain-specific)
NameTypeReqDescription
_app––SQD Explorer identity and host-render state.
_coverage––Window and result completeness.
_evidence––Replayable arguments, digest, row count, and receipt.
_execution––Bounded execution and scan details.
_freshness––Freshness and finality.
_llm––Hints to locate the primary evidence.
_meta––Network, block range, timing, and row counts.
_noticestring–Limitation or truncation notice.
_noticesarray–Limitation or truncation notices.
_ordering––Ordering guarantees.
_pagination––Pagination state and next_cursor.
_serverobject–SQD server name, exact version, and git commit.
_summarystring–Human-readable summary.
_tool_contract––Tool identity, intent, and chain families.
_ui––Chart, table, and follow-up presentation metadata.
answerstring–Answer grounded in the returned data.
display––Labels for presenting the result.
errorobject–Structured failure details.
investigation––Evidence paths, pivots, and limitations.
itemsarray–Primary rows for list results.
next_steps––Safe follow-up actions and continuation guidance.
pipes_handoff––SQD Pipes guidance for custom data needs.
value––Primary scalar result.

No examples provided.

portal_evm_query_token_transfers ~535

Query token-transfer activity on EVM without needing to remember Transfer event signatures. Best for "did token X move?" and asset-tracing questions. COMMON USER ASKS: - Recent USDC transfers - First recent USDC transfer WHEN TO USE: - You want ERC-20 style transfer activity filtered by token, sender, or recipient. - You want the fastest answer to a token movement question like "did USDC move?". - You are tracing suspicious, stolen, bridged, or exploit-related token movement and need sender/recipient/transaction pivots. - You want the easiest raw transfer query on an EVM network. - You need the first matching transfer in a bounded window without typing the Transfer topic hash. DON'T USE: - You need arbitrary event logs beyond token transfers. EXAMPLES: - Recent USDC transfers: {"network":"base-mainnet","timeframe":"1h","token_symbols":["USDC"],"limit":20} - First recent USDC transfer: {"network":"base-mainnet","timeframe":"1h","token_symbols":["USDC"],"scan_order":"earliest","limit":1}

NameTypeReqDescription
cursorstring–Continuation cursor from a previous response
from_addressesarray–Sender addresses
from_blocknumber–Starting block number
from_timestamp––Starting timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "1h ago".
include_token_infoboolean–Include token metadata (symbol, decimals) inline. Avoids separate token metadata lookups.
limitnumber–Max transfers
max_token_symbol_matchesnumber–Maximum token-list matches to include per token symbol. Use token_addresses for deterministic single-contract filters.
networkstring–Network name or alias. Optional when continuing with cursor.
scan_orderstring–Which side of the block window to scan first. Use earliest for first-transfer questions.
timeframestring–Time range (e.g., '1h', '24h'). Alternative to block numbers.
to_addressesarray–Recipient addresses
to_blocknumber–Ending block number. RECOMMENDED: <10k blocks for fast responses.
to_timestamp––Ending timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "now".
token_addressesarray–Token contract addresses
token_symbolsarray–Token symbols to resolve via open token-list data, e.g. ["USDC"]. Merges with token_addresses.
NameTypeReqDescription
_app––SQD Explorer identity and host-render state.
_coverage––Window and result completeness.
_evidence––Replayable arguments, digest, row count, and receipt.
_execution––Bounded execution and scan details.
_freshness––Freshness and finality.
_llm––Hints to locate the primary evidence.
_meta––Network, block range, timing, and row counts.
_noticestring–Limitation or truncation notice.
_noticesarray–Limitation or truncation notices.
_ordering––Ordering guarantees.
_pagination––Pagination state and next_cursor.
_serverobject–SQD server name, exact version, and git commit.
_summarystring–Human-readable summary.
_tool_contract––Tool identity, intent, and chain families.
_ui––Chart, table, and follow-up presentation metadata.
answerstring–Answer grounded in the returned data.
display––Labels for presenting the result.
errorobject–Structured failure details.
investigation––Evidence paths, pivots, and limitations.
itemsarray–Primary rows for list results.
next_steps––Safe follow-up actions and continuation guidance.
pipes_handoff––SQD Pipes guidance for custom data needs.
value––Primary scalar result.

No examples provided.

portal_evm_query_traces ~1,013

Query raw EVM traces: internal calls, contract creations, self-destructs, and block rewards, filtered by caller, callee, method, deployer, or one transaction, with the parent transaction hash on every row. COMMON USER ASKS: - Internal calls of one transaction - Recent internal calls into a contract - Contracts deployed by an address FIRST CHOICE FOR: - what a transaction called internally, including value moved by internal calls - contracts deployed by an address, or the internal call tree behind an incident WHEN TO USE: - You need the internal calls of a transaction: which contracts it called, with what selector and value, and which calls failed. - You want contracts created by a deployer or the creation trace of a contract. - You are tracing an exploit or incident below the top-level transaction and log surface. - You want internal ETH transfers between contracts that emit no event. DON'T USE: - You only need top-level transactions or event logs; those tools are cheaper. - You need storage changes; state diffs are not exposed by this tool. EXAMPLES: - Internal calls of one transaction: {"network":"ethereum-mainnet","from_block":12244145,"to_block":12244145,"transaction_hash":"0x851bad0415758075a1eb86776749c829b866d43179c57c3e4a4b9359a0358231","limit":25} - Recent internal calls into a contract: {"network":"base-mainnet","timeframe":"10m","type":["call"],"call_to":["0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"],"method":"transfer","limit":20} - Contracts deployed by an address: {"network":"base-mainnet","timeframe":"24h","type":["create"],"create_from":["0x4200000000000000000000000000000000000006"],"limit":10}

NameTypeReqDescription
call_fromarray–FILTER (call traces): calling addresses, contracts or wallets.
call_sighasharray–FILTER (call traces): 4-byte selectors such as 0xa9059cbb.
call_toarray–FILTER (call traces): called addresses.
create_fromarray–FILTER (create traces): deployer addresses.
create_result_addressarray–FILTER (create traces): deployed contract addresses.
cursorstring–Continuation cursor from a previous response
field_presetstring–Field preset: 'minimal' (type, from, to), 'standard' (value, selector, gas, result address), 'full' (adds call input and output and creation code).
finalized_onlyboolean–Only query finalized blocks
from_blocknumber–Starting block number (use this OR timeframe)
from_timestamp––Starting timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "1h ago".
include_subtracesboolean–Also return the child traces of each matching trace
include_transactionboolean–Attach the parent transaction (sender, recipient, value, status). The hash is always attached.
limitinteger–Max traces to return (default: 20, max: 25)
max_scan_blocksinteger–Safety cap for bounded scans. Default: 5,000 blocks with filters, 100 without.
method––FILTER (call traces): method alias such as transfer, approve, deposit, or a 4-byte selector. Merges with call_sighash.
networkstring–Network name or alias. Optional when continuing with cursor.
response_formatstring–Response format: defaults to 'compact' for chat-friendly output. Use 'summary' for counts by type, failures, value moved, and top callers.
scan_orderstring–Which side of the block window to scan first. Use earliest for first-occurrence questions.
timeframestring–Time range (e.g., '10m', '1h'). Alternative to from_block/to_block. Keep it short for traces.
to_blocknumber–Ending block number. Traces are expensive: keep filtered windows under 5,000 blocks.
to_timestamp––Ending timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "now".
transaction_hashstring–FILTER: keep only traces of this transaction. Give its block (from_block = to_block) or a window of at most 1,000 blocks; find the block with portal_evm_query_transactions first when unknown.
typearray–FILTER: trace types. 'create' covers both CREATE and CREATE2; 'reward' only exists on proof-of-work history.
NameTypeReqDescription
_app––SQD Explorer identity and host-render state.
_coverage––Window and result completeness.
_evidence––Replayable arguments, digest, row count, and receipt.
_execution––Bounded execution and scan details.
_freshness––Freshness and finality.
_llm––Hints to locate the primary evidence.
_meta––Network, block range, timing, and row counts.
_noticestring–Limitation or truncation notice.
_noticesarray–Limitation or truncation notices.
_ordering––Ordering guarantees.
_pagination––Pagination state and next_cursor.
_serverobject–SQD server name, exact version, and git commit.
_summarystring–Human-readable summary.
_tool_contract––Tool identity, intent, and chain families.
_ui––Chart, table, and follow-up presentation metadata.
answerstring–Answer grounded in the returned data.
display––Labels for presenting the result.
errorobject–Structured failure details.
investigation––Evidence paths, pivots, and limitations.
itemsarray–Primary rows for list results.
next_steps––Safe follow-up actions and continuation guidance.
pipes_handoff––SQD Pipes guidance for custom data needs.
value––Primary scalar result.

No examples provided.

portal_evm_query_transactions ~1,466

Query raw EVM transactions with optional logs, traces, state-diff context, and evidence pivots for transaction-level investigations. COMMON USER ASKS: - Recent Base transactions - Filter by sender - First EIP-2930 transaction from Berlin fork WHEN TO USE: - You need raw transaction records on an EVM network. - You want chain-specific transaction fields or include flags that convenience tools do not expose. - You need exact transaction evidence for an investigation, including sender, receiver, transaction hash, logs, traces, or failed calls. - You need to find the first transaction matching a raw field condition such as transaction type 0x1 from a known block. - You need top-N raw transactions ranked by value, gas used, or effective gas price. - You need top senders or receivers from a bounded transaction window. - You want common method names such as transfer, approve, deposit, or withdraw instead of remembering sighashes. - You want calls to a token contract by symbol, such as transfer calls to USDC, without hardcoding token addresses. DON'T USE: - You only need a quick recent feed or wallet-level summary. EXAMPLES: - Recent Base transactions: {"network":"base-mainnet","timeframe":"1h","limit":20} - Filter by sender: {"network":"ethereum-mainnet","timeframe":"6h","from_addresses":["0xabc..."],"limit":20} - First EIP-2930 transaction from Berlin fork: {"network":"ethereum-mainnet","from_block":12244000,"transaction_type":"0x1","scan_order":"earliest","limit":1,"field_preset":"minimal"} - Largest recent calls to a resolved token contract: {"network":"base-mainnet","timeframe":"1h","to_token_symbols":["USDC"],"method":"transfer","order_by":"gas_used_desc","limit":5} - Top senders by transaction count: {"network":"base-mainnet","timeframe":"1h","aggregate_by":"sender","aggregate_metric":"count","limit":10}

NameTypeReqDescription
aggregate_bystring–Optional bounded aggregation for top sender/receiver questions. Returns ranked address rows instead of raw transactions.
aggregate_metricstring–Metric used with aggregate_by. count ranks by tx count; value by total native value; gas_used by total gas used; effective_gas_price by max effective gas price.
contract_creationboolean–FILTER: true returns contract-creation transactions; false excludes them. Useful for "first contract creation from this wallet".
cursorstring–Continuation cursor from a previous response
field_presetstring–Field preset: 'minimal' (from/to/value+block, ~70% smaller), 'standard' (hash+gas+timestamp), 'full' (includes input data hex, largest). Use 'minimal' to reduce context usage.
finalized_onlyboolean–Only query finalized blocks
first_noncenumber–Minimum nonce
from_addressesarray–FILTER: Sender addresses (wallets or contracts that initiated the transaction). Optional if limit <=100.
from_blocknumber–Starting block number (use this OR timeframe). Large ranges OK with low limit (<=100).
from_timestamp––Starting timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "1h ago".
from_token_symbolsarray–Resolve token symbols via open token-list data and merge them into from_addresses. Rare, but useful for token-contract-originated transactions.
include_l2_fieldsboolean–Include L2-specific fields
include_logsboolean–Include logs emitted by transactions
include_state_diffsboolean–Include state diffs caused by transactions
include_tracesboolean–Include traces for transactions
last_noncenumber–Maximum nonce
limitinteger–Max transactions (default: 20, max: 25). This verified ceiling keeps pages within MCP client budgets.
max_scan_blocksnumber–Safety cap for first/last/ranked client-side scans. Default: min(window, 10000 blocks).
max_token_symbol_matchesnumber–Maximum token-list matches to include per token symbol. Use from_addresses/to_addresses for deterministic single-contract filters.
method––FILTER: Common EVM method alias or 4-byte sighash. Examples: "transfer", "approve", "transferFrom", "deposit", "withdraw". Merges with sighash.
min_effective_gas_price_wei––FILTER/RANKING: Minimum effectiveGasPrice in wei. Accepts decimal or hex string.
min_gas_used––FILTER/RANKING: Minimum receipt gasUsed. Accepts decimal or hex string.
min_value_wei––FILTER/RANKING: Minimum native token value in wei. Accepts decimal or hex string.
networkstring–Network name or alias. Optional when continuing with cursor.
order_bystring–Optional ranking for top-N questions. Use value_desc, gas_used_desc, or effective_gas_price_desc.
response_formatstring–Response format: defaults to 'compact' for chat-friendly output, or stays 'full' when inline logs, traces, or state diffs are requested. Use 'summary' for counting or profiling.
scan_orderstring–Which side of the block window to scan first. Normal previews default to latest; transaction_type searches default to earliest, so "first tx type 0x1 from block N" scans forward from from_block.
sighasharray–FILTER: Function sighash (4-byte hex, e.g., '0xa9059cbb' for transfer). Optional if limit <=100.
timeframestring–Natural time range such as '5m', '1h', '24h', '7d', or 'past 30 minutes'. Alternative to from_block/to_block. Large ranges are allowed with a low limit (<=100).
to_addressesarray–FILTER: Recipient addresses (typically contracts being called, or wallets receiving ETH). Optional if limit <=100.
to_blocknumber–Ending block number. RECOMMENDED: <5k blocks for fast (<500ms) responses. Larger ranges may be slow.
to_timestamp––Ending timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "now".
to_token_symbolsarray–Resolve token symbols via open token-list data and merge them into to_addresses, e.g. transfer/approve calls to USDC.
transaction_status––FILTER: Transaction receipt status. Use "success"/1 or "failed"/0 for failed/reverted transaction searches.
transaction_type––FILTER: EVM transaction type. Accepts decimal or hex strings such as 0, 1, 2, "0x0", "0x1", "0x2". Applied client-side while streaming Portal results; use with scan_order="earliest" and from_block to…
NameTypeReqDescription
_app––SQD Explorer identity and host-render state.
_coverage––Window and result completeness.
_evidence––Replayable arguments, digest, row count, and receipt.
_execution––Bounded execution and scan details.
_freshness––Freshness and finality.
_llm––Hints to locate the primary evidence.
_meta––Network, block range, timing, and row counts.
_noticestring–Limitation or truncation notice.
_noticesarray–Limitation or truncation notices.
_ordering––Ordering guarantees.
_pagination––Pagination state and next_cursor.
_serverobject–SQD server name, exact version, and git commit.
_summarystring–Human-readable summary.
_tool_contract––Tool identity, intent, and chain families.
_ui––Chart, table, and follow-up presentation metadata.
answerstring–Answer grounded in the returned data.
display––Labels for presenting the result.
errorobject–Structured failure details.
investigation––Evidence paths, pivots, and limitations.
itemsarray–Primary rows for list results.
next_steps––Safe follow-up actions and continuation guidance.
pipes_handoff––SQD Pipes guidance for custom data needs.
value––Primary scalar result.

No examples provided.

portal_get_head ~160

Get just the latest indexed head block or slot for a network. COMMON USER ASKS: - Latest head - Finalized head FIRST CHOICE FOR: - getting the current indexed head before building a manual block range WHEN TO USE: - You only need the current block or slot number. - You need the current head before building a raw block-range query. DON'T USE: - You want to know if the network is caught up, behind, fresh, or what tables are available. EXAMPLES: - Latest head: {"network":"base-mainnet"} - Finalized head: {"network":"ethereum-mainnet","type":"finalized"}

NameTypeReqDescription
networkstringyesNetwork name or alias
typestring–Block type
NameTypeReqDescription
_app––SQD Explorer identity and host-render state.
_coverage––Window and result completeness.
_evidence––Replayable arguments, digest, row count, and receipt.
_execution––Bounded execution and scan details.
_freshness––Freshness and finality.
_llm––Hints to locate the primary evidence.
_meta––Network, block range, timing, and row counts.
_noticestring–Limitation or truncation notice.
_noticesarray–Limitation or truncation notices.
_ordering––Ordering guarantees.
_pagination––Pagination state and next_cursor.
_serverobject–SQD server name, exact version, and git commit.
_summarystring–Human-readable summary.
_tool_contract––Tool identity, intent, and chain families.
_ui––Chart, table, and follow-up presentation metadata.
answerstring–Answer grounded in the returned data.
display––Labels for presenting the result.
errorobject–Structured failure details.
investigation––Evidence paths, pivots, and limitations.
itemsarray–Primary rows for list results.
next_steps––Safe follow-up actions and continuation guidance.
pipes_handoff––SQD Pipes guidance for custom data needs.
value––Primary scalar result.

No examples provided.

portal_get_network_info ~145

Answer "is this network caught up?" with indexing freshness, lag, heads, and available tables. COMMON USER ASKS: - Is Base caught up? FIRST CHOICE FOR: - checking indexing head, lag, tables, and capabilities for one network WHEN TO USE: - You want to know whether a network is indexed, fresh, caught up, or behind before querying. - You need chain family, real-time status, or available tables for a network. DON'T USE: - You only need the latest block or slot number. EXAMPLES: - Is Base caught up?: {"network":"base-mainnet"}

NameTypeReqDescription
networkstringyesNetwork name or alias
NameTypeReqDescription
_app––SQD Explorer identity and host-render state.
_coverage––Window and result completeness.
_evidence––Replayable arguments, digest, row count, and receipt.
_execution––Bounded execution and scan details.
_freshness––Freshness and finality.
_llm––Hints to locate the primary evidence.
_meta––Network, block range, timing, and row counts.
_noticestring–Limitation or truncation notice.
_noticesarray–Limitation or truncation notices.
_ordering––Ordering guarantees.
_pagination––Pagination state and next_cursor.
_serverobject–SQD server name, exact version, and git commit.
_summarystring–Human-readable summary.
_tool_contract––Tool identity, intent, and chain families.
_ui––Chart, table, and follow-up presentation metadata.
answerstring–Answer grounded in the returned data.
display––Labels for presenting the result.
errorobject–Structured failure details.
investigation––Evidence paths, pivots, and limitations.
itemsarray–Primary rows for list results.
next_steps––Safe follow-up actions and continuation guidance.
pipes_handoff––SQD Pipes guidance for custom data needs.
value––Primary scalar result.

No examples provided.

portal_get_recent_activity ~458

Get a simple recent-activity feed across EVM, Solana, Bitcoin, or Hyperliquid with chronological paging and investigation pivots. COMMON USER ASKS: - Recent activity on Base - Recent Hyperliquid fills FIRST CHOICE FOR: - recent activity on any supported network without manual block math - questions like "what has been happening on Base lately?" - first-pass incident triage when the user asks what happened recently on a network WHEN TO USE: - You want a quick recent-activity feed for a network. - You want to ask what has been happening lately on a network and see the newest activity first. - You want the simplest starting point before reaching for raw VM-specific query tools. - You are investigating an incident and need a bounded, recent evidence timeline before narrowing to wallets, transfers, logs, or fills. DON'T USE: - You need raw logs, instructions, or chain-specific fields that only raw query tools return. - You want a chart over time rather than a recent feed. EXAMPLES: - Recent activity on Base: {"network":"base-mainnet","timeframe":"1h","limit":10} - Recent Hyperliquid fills: {"network":"hyperliquid-fills","timeframe":"1h","limit":10}

NameTypeReqDescription
cursorstring–Continuation cursor from a previous response
from_addressesarray–Filter by sender addresses
from_timestamp––Starting timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "1h ago".
limitinteger–Max activity rows to return (default: 10, max: 25)
networkstring–Network name (supports short names: 'polygon', 'base', 'ethereum', 'arbitrum', etc.). Optional when continuing with cursor.
timeframestring–Time period or block count. Examples: '100' (default), '1h', '6h', '24h', '7d', '3d'.
to_addressesarray–Filter by recipient addresses
to_timestamp––Ending timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "now".
NameTypeReqDescription
_app––SQD Explorer identity and host-render state.
_coverage––Window and result completeness.
_evidence––Replayable arguments, digest, row count, and receipt.
_execution––Bounded execution and scan details.
_freshness––Freshness and finality.
_llm––Hints to locate the primary evidence.
_meta––Network, block range, timing, and row counts.
_noticestring–Limitation or truncation notice.
_noticesarray–Limitation or truncation notices.
_ordering––Ordering guarantees.
_pagination––Pagination state and next_cursor.
_serverobject–SQD server name, exact version, and git commit.
_summarystring–Human-readable summary.
_tool_contract––Tool identity, intent, and chain families.
_ui––Chart, table, and follow-up presentation metadata.
answerstring–Answer grounded in the returned data.
display––Labels for presenting the result.
errorobject–Structured failure details.
investigation––Evidence paths, pivots, and limitations.
itemsarray–Primary rows for list results.
next_steps––Safe follow-up actions and continuation guidance.
pipes_handoff––SQD Pipes guidance for custom data needs.
value––Primary scalar result.

No examples provided.

Common questions

What is the SQD MCP server?

SQD is an MCP server listed in the public MCP registry as io.github.subsquid-labs/portal-mcp-server. Query 130+ SQD Portal datasets across blockchains, including native Tron transactions and events. This page covers its hosted endpoint (https://portal.sqd.dev/mcp).

Is the SQD MCP server safe to use?

SQD scores 78 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the SQD MCP server expose?

SQD exposes 31 tools: portal_list_networks, portal_get_network_info, portal_get_head, portal_resolve_entity, portal_get_recent_activity, and 26 more. Their descriptions and schemas cost roughly 17,229 tokens of context every time the server is loaded.

Does the SQD MCP server require authentication?

No. We connected to SQD without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

Is the SQD MCP server still maintained?

SQD is still listed as active in the MCP registry. We last reached this channel on 24 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.