SQD
OfficialSQD is a read-only MCP server for discovering networks and querying/analyzing indexed blockchain data with evidence, freshness, coverage, and pagination metadata.
Discover networks and resolve token symbols, contracts, pools, protocols, and Hyperliquid coins into query-ready filters.
Check network indexing status, latest/finalized heads, and convert timestamps to block/slot ranges.
Get recent activity feeds, wallet fund-flow summaries, and time-series charts/comparisons.
Query EVM transactions, logs/events, token transfers, contract deployments, contract activity, analytics, and DEX OHLC candles.
Query Solana transactions/instructions/analytics, Bitcoin transactions/analytics, Substrate events/calls/analytics, and Hyperliquid fills/analytics/OHLC.
Use advanced/debug tools for raw blocks, time-to-block resolution, and Hyperliquid replica-command records.
Receive compact/full/summary responses with safe follow-up actions, chart/table descriptors, and optional Explorer UI support.
Allows querying Bitcoin blockchain transactions and network analytics.
Provides tools for querying Ethereum blockchain data including transactions, logs, token transfers, contract deployment and activity, network analytics, and OHLC price candles.
Provides tools for querying the Optimism network (EVM-based) including transactions, logs, token transfers, contract analytics, and OHLC prices.
Allows querying Solana blockchain transactions, instructions, and network analytics.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@SQD Get wallet summary for 0xabc on Ethereum"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
SQD Portal MCP Server
An MCP server that answers blockchain questions from SQD Portal data: transactions, logs, traces, token transfers, wallets, analytics, time series, and candles across EVM, Solana, Bitcoin, Substrate, Hyperliquid, and Tron networks, with an optional in-host Explorer.
The server does not index chains itself. It validates input, plans bounded Portal queries, and returns results with coverage, freshness, pagination, and evidence metadata so an assistant can say exactly what it saw. No SQD account, API key, or client credential is required.
It speaks the stateless MCP 2026-07-28 protocol over HTTP and stdio and keeps the SDK-managed legacy negotiation path for clients still rolling out that revision. Release notes are in CHANGELOG.md. See CONTRIBUTING.md to work on the code and SECURITY.md to report a vulnerability.
Current public surface
28public tools3advanced/debug toolspublic params use
networkdiscovery filters use
vmno legacy tool aliases in
v0.8.x
Raw query tools default to compact responses. Ask for response_format: "full" only when you need the larger payload.
Entity questions can use portal_resolve_entity first. It resolves EVM token symbols/addresses, EVM contract aliases, pool identifiers, protocol names, and Hyperliquid coin names into query-ready filters while keeping ambiguous matches explicit.
Token symbol resolution and token metadata come from open token-list data, not baked-in token address constants. Responses include explicit notices when token-list data is unavailable, stale, or unsupported for a network.
Wallet questions should start with portal_get_wallet_summary. It returns fund_flow by default, including inbound/outbound movement, asset flows, counterparties, largest observed movements, and next evidence pivots before raw-tool drill-down.
Related MCP server: aipaygen-mcp
Tool groups
Discovery:
portal_list_networksportal_get_network_infoportal_get_headportal_resolve_entity
Cross-chain convenience:
portal_get_recent_activityportal_get_wallet_summaryportal_get_time_series
EVM:
portal_evm_query_transactionsportal_evm_query_logsportal_evm_query_tracesportal_evm_query_token_transfersportal_evm_get_contract_deploymentportal_evm_get_contract_activityportal_evm_get_analyticsportal_evm_get_ohlc
Solana:
portal_solana_query_transactionsportal_solana_query_instructionsportal_solana_get_analytics
Bitcoin:
portal_bitcoin_query_transactionsportal_bitcoin_get_analytics
Substrate:
portal_substrate_query_eventsportal_substrate_query_callsportal_substrate_get_analytics
Hyperliquid:
portal_hyperliquid_query_fillsportal_hyperliquid_get_analyticsportal_hyperliquid_get_ohlc
Tron:
portal_tron_query_transactionsportal_tron_query_logs
Advanced/debug:
portal_debug_query_blocksportal_debug_resolve_time_to_blockportal_debug_hyperliquid_query_replica_commands
These groups are also the toolsets (discovery, convenience, evm, solana, bitcoin, substrate, hyperliquid, tron, debug). A deployment can trim the catalog with MCP_TOOLSETS or MCP_TOOLS, and an HTTP connection can narrow it further with ?toolsets= or an X-MCP-Toolsets header; see the HTTP deployment notes. With nothing configured the full 31-tool surface is served, and the hosted endpoint keeps that default.
Supported data
EVM networks indexed by Portal, including Base, Ethereum, Optimism, Arbitrum, Monad, Hyperliquid EVM, and many others
Tron native transactions (TRX transfers, TRC-10 transfers, contract calls with inline logs and internal transactions) and TVM event logs such as TRC-20 transfers, with Base58 or hex addresses, exact TRX amounts, and the parent transaction hash on every log; the bundled SQD plugin skill documents the raw Stream API for anything beyond that
Solana mainnet
Bitcoin mainnet
Hyperliquid fills and replica commands
Substrate networks indexed by Portal
Substrate support is currently historical only. It does not have a real-time tail.
Response shape
Most tools return the same envelope in MCP structuredContent and in a compact JSON text fallback for older clients. The envelope contains a normal result body plus shared metadata such as:
answerdisplaynext_stepsinvestigation_freshness_coverage_pagination_ordering
investigation is a compact evidence guide for agents: it identifies the primary result path, bounded window, useful pivot fields such as addresses or transaction hashes, follow-up filters, and limitations before a result is treated as complete. Successful material results also carry an _evidence receipt with canonical arguments, a deterministic digest, row reconciliation, source windows, and either exact or semantic replay semantics. Exact receipts pin their evidence window. Semantic receipts disclose that rerunning a moving relative window can return a newer snapshot.
When a response uses estimated, partial, sampled, capped, or paginated data, the top-level answer and metadata disclose it. _pagination.has_more is true exactly when next_cursor is present, and _coverage states whether the requested window was read through (window_complete) and whether the response holds every matching row (result_complete). Safe pagination follow-ups include executable tool-call metadata with explicit cursor arguments; suggestions that cannot be reconstructed safely are marked non-executable.
Chart-oriented tools also return chart and table descriptors so MCP clients or LLMs can render them without reverse-engineering the payload.
SQD Explorer (beta)
SQD Explorer is an MCP App that renders tool results inside hosts that support MCP Apps. It is in beta and off by default. A default deployment answers with structuredContent and compact JSON text only, and no tool result asks a host to open a UI. There are two ways to opt in:
One connection: add
?app=1to the endpoint, for examplehttps://portal.sqd.dev/mcp?app=1. Use this to try the beta without changing anything for other users.Whole deployment: set
MCP_APP_ENABLED=true. A connection can still override it in either direction, so?app=0opts a single client back out.
The app resource stays registered either way, so a host can read it directly without anyone opting in.
When it is enabled, compatible hosts receive an inline card sized to its content and a full-screen workspace for 21 data tools: metrics led by the primary number, multi-series and signed-value charts, price candles with linked volume and a fixed readout, ranked and timeline panels that show ten rows with a Show all control, evidence tables that page ten rows with search across every row, explorer links for addresses, hashes, and blocks, chain logos and names from SQD network metadata, continuation controls, current-session history, and JSON or CSV export through the host. Pointer and keyboard inspection expose exact plotted values. Missing buckets remain visible as gaps, identifiers stay unshortened, and any local row cap is separate from server completeness. Failed follow-ups keep the last good result under the error. The app is self-contained and does not use persistent browser storage; its only browser-side requests are chain logo images from cdn.subsquid.io and sqd.dev, the two origins declared in the resource CSP. Hosts without MCP App support receive the same structuredContent and compact JSON text fallback, so the underlying answer never depends on the UI. docs/explorer-design.md records the design rules the app follows.
Three MCP prompts provide reproducible starting points without adding tools:
investigate-walletinvestigate-contractinvestigate-market
For a chart-first demo, ask: Show BTC price action and trading volume on Hyperliquid for the past hour, using five-minute candles. Explain whether the final candle is closed. The result opens the SQD Explorer with a candle chart, volume, an evidence table, requested and indexed time bounds, and a receipt. Replay the returned requested_window_start_timestamp and requested_window_end_exclusive as fixed from_timestamp and to_timestamp inputs when you need a stable verification run.
Try it in Claude
The hosted endpoint has the Explorer off, so a new user opts their own connection in:
In claude.ai or Claude Desktop, open Settings → Connectors → Add custom connector, enter
https://portal.sqd.dev/mcp?app=1, and choose no authentication. The?app=1turns the beta on for this connection only. On Claude Desktop you can instead installsqd.mcpbfrom the latest release and switch on its "SQD Explorer (beta)" setting.Start a new chat and enable the SQD connector for it.
Ask a data question. Any of these lands on a tool that carries the Explorer:
What has this wallet been doing on Base lately?with an address (wallet summary)Show me recent activity on Ethereum(recent activity)Chart transaction counts on Base for the last 15 minutes in five-minute buckets(time series)
The result renders as an inline card instead of a block of text; open the card for the full-screen workspace. Only the 21 data tools carry the Explorer. A catalogue question such as Which networks do you support? calls portal_list_networks and answers in plain text, which is expected rather than a failure.
Install
npm install
npm run buildRun
stdio:
npm startHTTP:
npm run start:httpDeveloper discovery
The server exposes a structured tool-selection guide for client builders:
MCP resource
sqd://toolsreturns grouped tool metadata, examples, starting points, and integration notes.MCP resource
sqd://tools/{name}returns the guide entry for one tool, for examplesqd://tools/portal_get_time_series.
Tool and resource discovery stays on the MCP protocol itself. The server does not maintain a duplicate HTTP catalog.
Codex plugin
The Codex plugin wrapper lives in plugins/portal and defaults to the hosted MCP endpoint at https://portal.sqd.dev/mcp.
Install it from the GitHub marketplace:
codex plugin marketplace add subsquid-labs/portal-mcp-server
codex plugin add portal@sqdFrom a clone of this repository, codex plugin marketplace add . registers the local copy instead.
Open a new Codex thread after installing. First-use prompts include Hyperliquid BTC perp fills, recent Base transaction volume, and the latest USDC transfers on Base.
Claude Code plugin
The Claude Code plugin uses the same hosted MCP endpoint and the same public selector:
claude plugin marketplace add subsquid-labs/portal-mcp-server
claude plugin install portal@sqdOpen a new Claude Code session after installing so the SQD MCP tools are loaded.
Grok
Grok chat can use SQD as a custom connector:
Open
grok.com/connectors.Choose New Connector, then Custom.
Enter
https://portal.sqd.dev/mcpas the MCP server URL.Leave authentication unset.
Grok Build reads Claude Code plugins directly, so it uses the same package:
grok plugin install --trust subsquid-labs/portal-mcp-server#plugins/portalChatGPT
In a workspace with custom MCP apps enabled, open Settings → Apps → Create, enter https://portal.sqd.dev/mcp, choose no authentication, scan the tools, and create the draft app. The server is read-only and does not require user credentials.
Claude Desktop
Download sqd.mcpb from the latest release and open it: Claude Desktop installs the bundle with one click and lists the 31 tools. The bundle carries the server, its production dependencies, and one optional setting, "SQD Explorer (beta)", which is off by default. It needs Node 22 or newer on the machine.
Manual fallback, from a local clone after npm run build, add an entry like this to claude_desktop_config.json:
{
"mcpServers": {
"SQD": {
"command": "node",
"args": ["/absolute/path/to/sqd-portal-mcp-server/dist/index.js"]
}
}
}Usage notes
If you do not know the exact network name, start with
portal_list_networks.If you need recent indexed state, use
portal_get_network_infoorportal_get_headfirst.If the question is broad, start with
portal_get_recent_activity,portal_get_wallet_summary, orportal_get_time_seriesbefore dropping to raw queries.Time windows accept compact and natural wording such as
30m,past 30 minutes,in the past 1h,in last 38 mins,last hour, or30 minutes ago.Use
portal_evm_get_ohlcandportal_hyperliquid_get_ohlconly when you actually need candle-shaped output.For large or exploratory queries, prefer
response_format: "compact"unless you need the full record shape.
HTTP Deployment Notes
HTTP mode exposes MCP at / and /mcp, liveness at /health, and readiness at /ready. The hosted service exposes the same versioned health response at https://portal.sqd.dev/mcp/health.
MCP and health endpoints do not require authentication.
Tool and resource discovery use the MCP protocol; retired
/toolsand/tools.jsonroutes return404.Set
MCP_CURSOR_SECRETon any deployment running more than one process, so a cursor one instance issues is accepted by the next. Unset, each process signs with its own random key, and a cursor stops working across a restart or a load-balanced hop./healthreportsversionandcommit, the git commit the image was built from, and every tool result repeats both in_server. Docker Hub tags:latest,X.Y.Z, andX.Ycome only from av*release tag;edgeandsha-<commit>come from everymainpush. Pin a version tag in production./readyis200only after the dataset catalog has loaded once and the latest Portal probe succeeded withinMCP_READY_MAX_AGE_MS; otherwise it is503with areasonandRetry-After. Point orchestrator readiness checks at/readyand liveness checks at/health. The Docker image'sHEALTHCHECKuses/ready.The server binds
127.0.0.1unlessMCP_BINDsays otherwise, and every route checks theHostheader (andOrigin, when a browser sends one) against an allowlist, so a DNS-rebound page cannot reach a local instance. Loopback hosts and origins always pass; requests withoutOriginalways pass the origin check. A non-loopback bind must setMCP_ALLOWED_HOSTSandMCP_ALLOWED_ORIGINS; if either is missing the server logs a startup error and serves without that check. The Docker image setsMCP_BIND=0.0.0.0, so set both variables in the deployment, or*behind a proxy that already validates them.Every request is bounded: headers within
MCP_HEADERS_TIMEOUT_MS, the whole request withinMCP_REQUEST_TIMEOUT_MS, idle keep-alive withinMCP_KEEP_ALIVE_TIMEOUT_MS, and MCP bodies aboveMCP_MAX_BODY_BYTESare refused with413before parsing (411for a chunked body with no length).
Useful environment variables:
MCP_CURSOR_SECRETthe key pagination cursors are signed with. Set it on any deployment running more than one process. Unset, each process signs with its own random key, so a cursor issued by one instance is rejected by the next and clients lose their place across a restart or a load-balanced hop. It is also what stops a caller minting a cursor for a window the tool would never have offered.MCP_TOOLSETScomma-separated toolsets to serve (discovery,convenience,evm,solana,bitcoin,substrate,hyperliquid,tron,debug;allordefaultfor everything). Unknown names are ignored with a startup error. Wins overMCP_TOOLS. Default: all nine, the full 31-tool catalog.MCP_TOOLScomma-separated exact tool names to serve whenMCP_TOOLSETSis unset.Per connection,
?toolsets=evmon the endpoint URL or anX-MCP-Toolsets: evmheader narrows the deployment's set for that connection only; it can never add a toolset. Prompts that reference a tool outside the active set are not offered. The active set is a bounded label (all, one toolset name, orcustom) onmcp_tool_client_calls_total.MCP_BINDinterface to listen on, default127.0.0.1(0.0.0.0in the Docker image)MCP_ALLOWED_HOSTScomma-separated hostnames accepted inHost(port ignored) on top of loopback;*disables the check. Required for a non-loopback bind.MCP_ALLOWED_ORIGINScomma-separated hostnames accepted inOriginon top of loopback;*disables the check. Required for a non-loopback bind.MCP_REQUEST_TIMEOUT_MS,MCP_HEADERS_TIMEOUT_MS,MCP_KEEP_ALIVE_TIMEOUT_MSrequest timing bounds, defaults120000,30000,65000MCP_MAX_BODY_BYTESMCP request body cap, default1048576MCP_READY_PROBE_INTERVAL_MSandMCP_READY_MAX_AGE_MSreadiness probe cadence and freshness, defaults30000and90000MCP_APP_ENABLEDto offer the beta SQD Explorer to compatible hosts, default off. Acceptstrueor1. Per-connection?app=1and?app=0override it.MCP_TOOL_WEIGHT_BUDGETto bound the combined cost of active tool calls, default32. Measured profiles allow up to 32 lookups, 4 raw or summary calls, or 2 analytics calls at once while queued work remains cancellation-aware.MCP_TOOL_MAX_QUEUEto bound queued tool calls, default64MCP_TOOL_QUEUE_TIMEOUT_MSto bound tool admission wait time, default5000MCP_TOOL_CLIENT_WEIGHT_SHAREpercent of the weight budget one caller (one connection, identified by a hashed address) may hold at once, default50; never below the heaviest single tool so every tool stays schedulable.MCP_TOOL_CLIENT_MAX_QUEUEbounds one caller's queued calls, default16. A caller over its share gets the retryableoverloadedresult withreason: client_sharewhile others keep flowing.MCP_TRUST_PROXYset to1(or to the number of proxies in front of the server) to key fairness on the address those proxies observed instead of the socket address. The header is read only when the immediate peer is itself a trusted proxy, and the hop is counted from the right ofX-Forwarded-For, because a caller can write anything to the left of it. The address is hashed and never stored or labelled.MCP_TRUSTED_PROXY_PREFIXESa comma-separated list of address prefixes that count as your proxies, matched against the start of the peer address (for example203.0.113.or2606:4700:). Setting it replaces the default rather than adding to it, so include loopback or your private range if a co-located proxy also reaches the server. With it unset, loopback and private ranges are trusted, which is where a co-located proxy sits; on a shared private network that means any host on that network can present a forwarded address, so name your proxies explicitly there.MCP_SLOW_REQUEST_MSthreshold for one JSON line on stderr per slow tool call with admission wait and execution timings and the bounded client family, default5000.
Cost guardrails
Every scan bound in the server is compiled in and set per tool: a filtered trace scan stops at 5,000 blocks, a contract-deployment search at 1,000,000. Guardrails add a second ceiling above those that a deployment sets from the environment, so an endpoint under load can be turned down without a new image.
MCP_GUARDRAIL_MODEone ofoff(default),shadow, orenforce.MCP_GUARDRAIL_<CLASS>_<LIMIT>sets one ceiling, where<CLASS>isLOOKUP,RAW_QUERY,SUMMARY, orANALYTICS, and<LIMIT>isMAX_SCAN_BLOCKS,MAX_WINDOW_SECONDS, orMAX_UPSTREAM_BYTES. For exampleMCP_GUARDRAIL_RAW_QUERY_MAX_SCAN_BLOCKS=50000.
There are no numeric defaults. A class with nothing set has no extra ceiling,
so off and enforce with nothing configured are the same server. The only way a
guardrail changes behaviour is if you set a number.
shadow evaluates every ceiling and records what enforcing would have done,
without changing a single response. enforce acts:
A scan over its ceiling stops at the ceiling and reports what it covered through the same partial-coverage path a scan that hits its compiled bound already uses, so
_coverage.result_completebecomesfalseand the response names the blocks it searched. It never claims a complete answer it did not get.A query window over its ceiling is refused before anything is fetched, with the cap named in the error and the next steps, because there is no partial result to return for a request that was never allowed to start.
Four counters, all with bounded labels: mcp_guardrail_admitted_total{class},
mcp_guardrail_would_block_total{class,limit},
mcp_guardrail_blocked_total{class,limit}, and
mcp_guardrail_fail_open_total{reason}.
Recommended rollout. Set the ceilings you are considering and run shadow for
a week. Read mcp_guardrail_would_block_total: it is exactly the set of real
requests the ceiling would have cut. If that set is larger than you expected, the
ceiling is wrong, not the traffic. Move to enforce once it is the size you
intended.
Traces
Metrics say how often and how long; a trace says where the time went inside one
call. Traces are off unless you set OTEL_EXPORTER_OTLP_ENDPOINT. With it unset
nothing here is imported, allocated, or sent, and the OpenTelemetry packages need
not be installed at all.
The SDK is not a dependency of this package. It and its exporter pull about 74 packages against a published tarball of roughly 3.4MB, and almost nobody running this over stdio wants any of it, so they are declared as optional peers. To turn traces on, install them alongside the server and point it at your collector:
npm i @opentelemetry/sdk-node @opentelemetry/exporter-trace-otlp-httpOTEL_EXPORTER_OTLP_ENDPOINT=http://collector:4318One tool call is one tree:
mcp.request (HTTP only: method, transport)
└─ tools/call portal_evm_query_logs
├─ mcp.admission (the wait for a slot)
├─ portal.fetch (one per attempt: dataset, status, bytes, resend count)
├─ portal.fetch
└─ mcp.format_result (hashing the answer for the evidence receipt)OTEL_* variables are read by the OpenTelemetry SDK itself, so sampling,
headers, batching, and protocol are configured the standard way. The rest:
A
traceparenton the HTTP request, or in the tool call's_meta, makes the call part of the caller's trace rather than starting a new one. The_metavalue wins, because it is the more specific claim about which turn this call belongs to.Each Portal request carries a
traceparentnaming its own fetch span, so a Portal-side trace can join this one. Nothing is added when tracing is off.The JSON log lines carry
trace_idandspan_idwhile tracing is on, so a log event and its span can be looked up from each other./healthreports whether tracing is configured, whether it started, and whether argument capture is on.
Span attributes carry no arguments, addresses, hashes, cursors, or free text.
They are the tool name, its work class, the dataset, bounded counts, and a bounded
outcome. A span leaves the process for a collector the query itself never reaches,
so the rule is the one the metric labels follow, and stricter than the logs, which
at least stay on your own stderr. MCP_OTEL_INCLUDE_ARGS=1 adds the raw tool
arguments to the tool span. It is off by default and unsafe for production: a
tool argument is routinely a wallet address, and often a user's own words.
Tests
npm run test:offline builds, lints, typechecks, runs the unit tests, and runs every suite that needs no Portal access. npm run test:live runs the Portal-backed suites. RELEASE_ASSURANCE.md summarises what a release verifies, and scripts/README.md lists every suite.
License
Available Tools
31 toolsportal_bitcoin_get_analyticsAnalyze Bitcoin activityARead-only
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"}
Inputs: mode, network, to_block, timeframe, +5 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_bitcoin_query_transactionsFind Bitcoin transactionsARead-only
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}
Inputs: limit, cursor, network, to_block, +8 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_debug_hyperliquid_query_replica_commandsInspect Hyperliquid command recordsARead-only
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}
Inputs: user, limit, cursor, status, +9 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_debug_query_blocksInspect raw blocksARead-only
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}
Inputs: limit, cursor, network, to_block, +7 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_debug_resolve_time_to_blockMatch a time to a blockARead-only
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"}
Inputs: network (required), timestamp (required). Returns: _ui, _app, _llm, _meta, +19 more
portal_evm_get_analyticsAnalyze Ethereum and Base activityARead-only
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}
Inputs: mode, limit, cursor, network, +5 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_evm_get_contract_activityReview smart contract activityARead-only
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"}
Inputs: network (required), contract_address (required), mode, timeframe, +3 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_evm_get_contract_deploymentFind a contract deploymentARead-only
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"}
Inputs: network (required), contract, to_block, timeframe, +7 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_evm_get_ohlcChart token price historyARead-only
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","duration":"1h","interval":"5m","price_in":"auto","include_recent_trades":true}
Base Uniswap candles: {"network":"base-mainnet","source":"uniswap_v3_swap","pool_address":"0x","duration":"1h","interval":"5m","price_in":"auto"}
Base Uniswap v4 candles: {"network":"base-mainnet","source":"uniswap_v4_swap","pool_id":"0x","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","duration":"1h","interval":"5m","price_in":"token1"}
Inputs: fee, mode, cursor, source, +20 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_evm_query_logsFind smart contract eventsARead-only
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}
Inputs: event, limit, cursor, decode, +21 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_evm_query_token_transfersFind token transfersARead-only
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}
Inputs: limit, cursor, network, to_block, +11 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_evm_query_tracesFind internal calls and contract creationsARead-only
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}
Inputs: type, limit, cursor, method, +19 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_evm_query_transactionsFind Ethereum and Base transactionsARead-only
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}
Inputs: limit, cursor, method, network, +31 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_get_headGet the latest blockARead-only
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"}
Inputs: network (required), type. Returns: _ui, _app, _llm, _meta, +19 more
portal_get_network_infoCheck network statusARead-only
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"}
Inputs: network (required). Returns: _ui, _app, _llm, _meta, +19 more
portal_get_recent_activityView recent blockchain activityARead-only
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}
Inputs: limit, cursor, network, timeframe, +4 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_get_time_seriesChart blockchain activityARead-only
Build simple activity charts and other time-series views across supported VMs, including compare-previous windows and grouped EVM contract trends.
COMMON USER ASKS:
Base transactions per 5m bucket
Compare two periods
FIRST CHOICE FOR:
activity over time, compare-current-vs-previous, grouped trends, and simple activity charts
WHEN TO USE:
You want chart-ready metric buckets over time.
You want a simple activity chart. Use a shorter window on fast networks such as Base.
You want to compare the current period to the previous period.
DON'T USE:
You need raw record lists instead of aggregated buckets.
You need DEX pool candles or OHLC output.
EXAMPLES:
Base transactions per 5m bucket: {"network":"base-mainnet","metric":"transaction_count","duration":"15m","interval":"5m"}
Compare two periods: {"network":"solana-mainnet","metric":"transaction_count","duration":"1h","interval":"5m","compare_previous":true}
Inputs: metric (required), network (required), interval (required), mode, +7 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_get_wallet_summaryReview wallet activityARead-only
Summarize wallet activity and fund flow with shared overview, asset movement, counterparties, evidence pivots, and follow-up filters across supported networks.
COMMON USER ASKS:
EVM wallet fund-flow triage
Solana wallet activity and fee flow
FIRST CHOICE FOR:
one-call wallet analysis across supported VMs
suspicious wallet triage, fund-flow direction, counterparties, and next evidence pivots before drilling into raw records
WHEN TO USE:
You want a single high-level answer about what one wallet has been doing and where value appears to move.
You want inbound/outbound flow, activity and asset-movement counterparties, largest movements within each asset, and exact next pivots before drilling into raw transactions or fills.
The user asks to investigate a suspicious wallet, stolen-funds path, exploit counterparty, or incident address.
DON'T USE:
You need every raw record with full chain-specific fields and no summarization.
EXAMPLES:
EVM wallet fund-flow triage: {"network":"base-mainnet","address":"0xabc...","timeframe":"24h"}
Solana wallet activity and fee flow: {"network":"solana-mainnet","address":"Vote111...","timeframe":"6h"}
Inputs: mode, cursor, address, network, +7 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_hyperliquid_get_analyticsAnalyze Hyperliquid tradingARead-only
Get the big-picture Hyperliquid fill analytics with top traders, volume by coin, fees, and PnL.
COMMON USER ASKS:
Hyperliquid fill snapshot
Who traded the most?
WHEN TO USE:
You want network-level Hyperliquid fill analytics.
You want to know who traded the most, which coins had volume, or how fees and PnL looked.
You want grouped aggregate sections without stitching raw fills together yourself.
DON'T USE:
You need individual fill records or OHLC candles.
EXAMPLES:
Hyperliquid fill snapshot: {"network":"hyperliquid-fills","timeframe":"1h"}
Who traded the most?: {"network":"hyperliquid-fills","timeframe":"1h"}
Inputs: coin, mode, cursor, network, +5 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_hyperliquid_get_ohlcChart Hyperliquid pricesARead-only
Build chart-ready Hyperliquid trade OHLC candles with fixed buckets and auto intervals.
COMMON USER ASKS:
BTC candles
WHEN TO USE:
You want candles for one coin on Hyperliquid.
You need chart-ready OHLC, volume, and VWAP data from fills.
DON'T USE:
You want scalar time-series buckets or raw fills.
EXAMPLES:
BTC candles: {"network":"hyperliquid-fills","coin":"BTC","duration":"6h","interval":"auto"}
Inputs: coin, user, cursor, network, +4 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_hyperliquid_query_fillsFind Hyperliquid tradesARead-only
Query raw individual Hyperliquid fills with trader, coin, fee, PnL, and builder context.
COMMON USER ASKS:
Recent BTC fills
WHEN TO USE:
You need raw fill records on Hyperliquid.
You want to filter by trader, coin, direction, builder, or fee token.
DON'T USE:
You want the big picture, top traders, grouped aggregates, or candles instead of raw fill rows.
EXAMPLES:
Recent BTC fills: {"network":"hyperliquid-fills","timeframe":"1h","coin":["BTC"],"limit":20}
Inputs: dir, coin, user, cloid, +14 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_list_networksFind blockchain networksARead-only
Find the right network or chain name to use across EVM, Solana, Bitcoin, Substrate, and Hyperliquid.
COMMON USER ASKS:
Find Base-like networks
Show Solana mainnets
Show Substrate mainnets
FIRST CHOICE FOR:
finding the correct network before any other query
WHEN TO USE:
You are not sure which network name, chain name, or alias to use.
You want to filter networks by VM family, network type, or real-time availability.
DON'T USE:
You already know the exact network and want live data from that network.
EXAMPLES:
Find Base-like networks: {"query":"base","limit":10}
Show Solana mainnets: {"vm":"solana","network_type":"mainnet"}
Show Substrate mainnets: {"vm":"substrate","network_type":"mainnet"}
Inputs: vm, limit, query, cursor, +2 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_resolve_entityFind a token or contractARead-only
Resolve user-facing blockchain entities into query-ready identifiers, with ambiguity kept explicit.
COMMON USER ASKS:
Resolve USDC on Base
Resolve WETH on Ethereum
Resolve BAYC contract
FIRST CHOICE FOR:
resolving a token symbol like USDC to token contract addresses
resolving EVM contract aliases, protocol names, pool identifiers, or Hyperliquid coin names before querying
checking which token-list addresses a symbol maps to before querying logs or transfers
turning a user-friendly token name into deterministic EVM filters
WHEN TO USE:
The user names a token symbol such as USDC, WETH, DAI, or PEPE and you need contract addresses before querying raw data.
The user names a well-known EVM contract, protocol, pool identifier, or Hyperliquid ticker and you need a deterministic follow-up filter.
You need to disambiguate bridged token variants on an EVM network.
You want a source-backed token address rather than relying on memory or hardcoded constants.
DON'T USE:
You already have the exact address, pool id, protocol slug, or coin filter and can pass it directly.
EXAMPLES:
Resolve USDC on Base: {"network":"base-mainnet","kind":"token","query":"USDC","limit":10}
Resolve WETH on Ethereum: {"network":"ethereum-mainnet","kind":"token","query":"WETH","limit":5}
Resolve BAYC contract: {"network":"ethereum-mainnet","kind":"contract","query":"bored apes"}
Resolve Hyperliquid coin: {"kind":"hyperliquid_coin","query":"bitcoin"}
Inputs: query (required), kind, limit, network. Returns: _ui, _app, _llm, _meta, +19 more
portal_solana_get_analyticsAnalyze Solana activityARead-only
Get the big picture for Solana throughput, fees, wallet activity, and optional top-program usage.
COMMON USER ASKS:
Solana network snapshot
Include top programs
FIRST CHOICE FOR:
the big picture for Solana right now
WHEN TO USE:
You want the big picture for Solana right now.
You want a network health snapshot for Solana.
You want throughput, fee, success-rate, or top-program analytics rather than raw records.
DON'T USE:
You want chart buckets or raw transaction/instruction records.
EXAMPLES:
Solana network snapshot: {"network":"solana-mainnet","timeframe":"1h"}
Include top programs: {"network":"solana-mainnet","timeframe":"1h","include_programs":true}
Inputs: mode, cursor, network, timeframe, +6 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_solana_query_instructionsFind Solana program activityARead-only
Query raw Solana instructions with program and account filters.
COMMON USER ASKS:
Token Program instructions
WHEN TO USE:
You need program-level or account-level instruction activity.
You want to inspect Token Program, Jupiter, System Program, or Anchor discriminator activity.
DON'T USE:
You only need transaction-level activity and not individual instructions.
EXAMPLES:
Token Program instructions: {"network":"solana-mainnet","timeframe":"1h","program_id":["TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"],"limit":20}
Inputs: a0, a1, a2, a3, +35 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_solana_query_transactionsFind Solana transactionsARead-only
Query raw Solana transactions with optional balances, rewards, logs, and instruction context.
COMMON USER ASKS:
Recent Solana transactions
Filter by program
WHEN TO USE:
You need raw Solana transaction records.
You want Solana-specific filters or include flags that convenience tools do not expose.
DON'T USE:
You only want recent activity or a compact network summary.
EXAMPLES:
Recent Solana transactions: {"network":"solana-mainnet","timeframe":"1h","limit":20}
Filter by program: {"network":"solana-mainnet","timeframe":"1h","program_id":["TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"],"limit":20}
Inputs: limit, cursor, network, to_block, +13 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_substrate_get_analyticsAnalyze Polkadot activityARead-only
Analytics snapshot for Substrate or Polkadot activity in an indexed window, with event, call, and extrinsic counts plus top event and call names.
COMMON USER ASKS:
Polkadot activity snapshot
Big picture for Polkadot activity
How is Polkadot doing?
FIRST CHOICE FOR:
Polkadot activity analytics in an indexed window
how Polkadot is doing in an indexed window
analytics snapshot for Polkadot or another Substrate network in an indexed window
WHEN TO USE:
You want Polkadot activity analytics in a selected indexed window.
You want to ask "how is Polkadot doing in this indexed window?" and get an analytics answer rather than just network freshness metadata.
You want a quick Substrate network snapshot or health check.
You want top pallet events and calls rather than raw rows.
You want to know how a Substrate network is doing in the selected indexed window.
DON'T USE:
You need full raw event or call records.
EXAMPLES:
Polkadot activity snapshot: {"network":"polkadot","timeframe":"1h"}
Big picture for Polkadot activity: {"network":"polkadot","timeframe":"1h"}
How is Polkadot doing?: {"network":"polkadot","timeframe":"6h"}
Inputs: mode, network, to_block, timeframe, +5 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_substrate_query_callsFind Polkadot callsARead-only
Query raw Substrate or Polkadot calls with pallet/call-name filters and optional child-call, emitted-event, or extrinsic context.
COMMON USER ASKS:
Recent Balances calls
Polkadot calls with emitted events
FIRST CHOICE FOR:
raw Substrate or Polkadot call rows, especially when you want the events emitted by those calls
WHEN TO USE:
You need raw call records on a Substrate network.
You want pallet call activity like Balances.transfer_keep_alive or Ethereum.transact.
You want calls plus the events emitted by those calls.
DON'T USE:
You want events or aggregate analytics rather than call rows.
EXAMPLES:
Recent Balances calls: {"network":"polkadot","timeframe":"1h","call_names":["Balances.transfer_keep_alive"],"limit":20}
Polkadot calls with emitted events: {"network":"polkadot","timeframe":"1h","call_names":["ParaInherent.enter"],"include_events":true,"limit":20}
Inputs: limit, cursor, network, to_block, +11 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_substrate_query_eventsFind Polkadot eventsARead-only
Query raw Substrate or Polkadot event rows with pallet/event-name filters and optional parent call or extrinsic context.
COMMON USER ASKS:
Balances.Transfer events on Polkadot
FIRST CHOICE FOR:
raw Substrate or Polkadot event rows with optional parent call or extrinsic context
WHEN TO USE:
You need raw event records on a Substrate network.
You want pallet-level event activity like Balances.Transfer or Contracts.ContractEmitted.
You want event rows first, even if the network is a Polkadot-family chain.
DON'T USE:
You want calls or aggregate analytics rather than event rows.
EXAMPLES:
Balances.Transfer events on Polkadot: {"network":"polkadot","timeframe":"1h","event_names":["Balances.Transfer"],"limit":20}
Inputs: limit, cursor, network, to_block, +10 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_tron_query_logsFind Tron contract eventsARead-only
Query raw Tron (TVM) event logs by contract address and topics with common event aliases, the parent transaction hash on every row, and optional inline decoding.
COMMON USER ASKS:
Recent USDT transfers on Tron
USDT transfers received by one wallet
FIRST CHOICE FOR:
TRC-20 token transfer events on Tron such as USDT
contract event evidence on Tron with the parent transaction hash
WHEN TO USE:
You need TRC-20 Transfer or Approval events for a token such as USDT on Tron.
You need event logs from a Tron contract filtered by topic signature or indexed address.
You want the exact transaction hash behind each Tron event.
DON'T USE:
You want native TRX transfers or contract calls; use portal_tron_query_transactions.
You need an Ethereum-compatible network; use portal_evm_query_logs.
EXAMPLES:
Recent USDT transfers on Tron: {"network":"tron-mainnet","timeframe":"5m","addresses":["TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t"],"event":"transfer","decode":true,"limit":20}
USDT transfers received by one wallet: {"network":"tron-mainnet","from_block":84000000,"to_block":84000100,"addresses":["TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t"],"event":"transfer","topic2":["TJLuVi6UhS3UTx5EUXNCoz9VNqP2gnPmyf"],"decode":true,"limit":20}
Inputs: event, limit, cursor, decode, +15 more. Returns: _ui, _app, _llm, _meta, +19 more
portal_tron_query_transactionsFind Tron transactionsARead-only
Query raw Tron transactions: native TRX transfers, TRC-10 asset transfers, TriggerSmartContract calls by contract and method, or any contract type, with optional inline logs and internal transactions.
COMMON USER ASKS:
Recent native TRX transfers
USDT transfer calls in a block window
TRX sent from one wallet
FIRST CHOICE FOR:
native TRX transfers, TRC-10 transfers, and smart-contract calls on Tron
who sent TRX to an address on Tron, or which wallets called a Tron contract
WHEN TO USE:
You need raw Tron transaction records with sender, recipient, amount in TRX, fee, energy, and success.
You want native TRX transfers to or from a wallet in a bounded window.
You want calls to a Tron contract such as USDT filtered by method (transfer, approve) or caller.
You want TRC-10 asset transfers by asset id.
DON'T USE:
You need TRC-20 token events; those are logs, so use portal_tron_query_logs.
You need an Ethereum-compatible network; use portal_evm_query_transactions.
EXAMPLES:
Recent native TRX transfers: {"network":"tron-mainnet","timeframe":"5m","kind":"transfer","limit":20}
USDT transfer calls in a block window: {"network":"tron-mainnet","from_block":84000000,"to_block":84000010,"contract_addresses":["TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t"],"method":"transfer","limit":20}
TRX sent from one wallet: {"network":"tron-mainnet","timeframe":"1h","kind":"transfer","from_addresses":["TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t"],"limit":20}
Inputs: kind, asset, limit, types, +17 more. Returns: _ui, _app, _llm, _meta, +19 more
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 31 tools
Tools are cleanly partitioned by chain prefix plus resource/action (EVM logs vs traces vs transactions vs token transfers), and the descriptions explicitly cross-reference each other with DON'T USE pointers. The only real overlap is portal_evm_query_logs versus portal_evm_query_token_transfers, which is mitigated by explicit steering language. A few generic tools (recent_activity, time_series, analytics) could be confused at a glance but their descriptions draw clear lines.
Nearly all tools follow portal_<chain>_<verb>_<noun> (portal_evm_query_logs, portal_solana_get_analytics, portal_tron_query_logs). The get/query split is semantically meaningful (query = raw records, get = summaries/analytics) rather than arbitrary. Minor deviations like portal_debug_hyperliquid_query_replica_commands (chain mid-name) and the generic non-chain-prefixed tools keep it from a perfect score.
At 31 tools the surface is heavy, exceeding the typical comfortable range. It is partly justified because the server spans six VM families (EVM, Solana, Bitcoin, Substrate, Hyperliquid, Tron), each needing raw-query plus analytics tools. Still, there is some padding (debug_* tools, chain-specific OHLC duplicates) that could be consolidated.
The surface covers the full raw-record lifecycle across chains: transactions, logs/events, traces/calls, transfers, wallet summary, network info/head, and analytics per VM. Gaps are modest—Tron lacks analytics and trace-level tooling, Substrate lacks an extrinsics query (only counts), and Bitcoin block/address tooling is only reachable via debug tools. These are workaroundable rather than blocking.
Maintenance
Related MCP Connectors
Solana MCP for wallets, trades, markets, PnL, transfers, onchain data, signable swaps and API tools.
Hosted MCP gateway for Web3 infra discovery across 20+ networks via one endpoint.
Free read-only crypto whale-tracking & market-data MCP tools across 14 chains. No auth.
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
Related MCP Servers
- AlicenseAqualityBmaintenanceMCP server with 43 tools for blockchain data — token lookups, wallet balances, live chain queries across 10+ networks, and full API documentation search.27254 npmApache 2.0
- FlicenseNot gradedqualityCmaintenance250+ AI-powered MCP tools: research, write, code, translate, scrape, sentiment, vision, RAG, agent memory, marketplace, trading signals, and more. 15 models across 7 providers. Pay-per-use via API key or x402 USDC micropayments.2-
- AlicenseNot gradedqualityBmaintenanceProvides multichain block-explorer data from Etherscan via MCP tools for token balances, contract ABI, and source code.166 npmMIT
- AlicenseAqualityBmaintenanceEnables AI agents to query blockchain data across EVM chains and Sui through token-efficient MCP tools, including balances, transactions, logs, NFTs, token prices, and Sui objects/events, with optional TORPC tiered ABI decoding.25MIT