Skip to main content
Glama

Bitquery: Crypto & Blockchain Data

Solana Find Instructions

solana_find_instructions
Read-only

FIND Solana (sol, SOL, mainnet-beta) TRANSACTIONS BY PROGRAM INSTRUCTION — search one WALLET's value-moving records by the decoded method name and/or the program that produced them (e.g. "merge" of stake, "mintTo" / "closeAccount" of spl-token, "DecreaseLiquidity" of Orca), optionally pinned to one token by mint. Returns SLIM per-instruction records (signature, block, time, program, method, top-level program + method, inner call path, sender→receiver, amount, currency, mint) — one call instead of scanning whole transactions. A Currency of unknown: is a token without a known symbol or decimals: Mint identifies it and its Amount is in RAW base units. Inspect a found transaction with solana_tx_transfers.

WHAT IS SEARCHABLE — only records that move value or touch accounts (transfers, mints, burns, account create/close, stake operations), and only a FEW programs are decoded into method names. The common stored names, exactly as they appear:

  • spl-token: transfer, transferChecked, mintTo, mintToChecked, burn, burnChecked, closeAccount, initializeAccount3, setAuthority, syncNative

  • system: transfer, createAccount, createAccountWithSeed, transferWithSeed

  • spl-associated-token-account: create, createIdempotent; stake: merge, split, withdraw; address-lookup-table, bpf-upgradeable-loader, vote

  • Orca (Whirlpool, PascalCase): Swap, DecreaseLiquidity, CollectFees, CollectReward, OpenPositionWithMetadata Everything else is NOT decoded — Raydium (AMM, CPMM, CLMM, LaunchLab), pump.fun, PumpSwap, Jupiter and other DEX / launchpad / aggregator programs. Their own method names (swap, swap_base_input, buy_exact_in, migrate_to_cpswap, ...) are never stored in any spelling, so searching for them returns nothing. Such a program shows up only as its base58 id in Program / Outer_Program with an EMPTY Method: search it with program= plus an address and an empty instruction (or "transferChecked" / "transfer" for just the token legs it moved).

TWO LEVELS ONLY. Program/Method is the program that executed the record (usually spl-token or system); Outer_Program/Outer_Method is the TOP-LEVEL instruction of the transaction it sits in. Programs called in between are not recorded: a Raydium swap routed through an aggregator shows the aggregator as Outer_Program and Raydium nowhere, so program= finds only transactions that called Raydium directly.

ADDRESS must be a wallet (the OWNER that sent or received value). A token MINT, a token account or a pool / market account is never the sender or receiver of the swaps and transfers that involve it — pool funds sit under the DEX's shared vault authority, not under the pool address. Such an account usually appears only as the Receiver of the createAccount record that funded it, so address= with instruction=createAccount finds the transaction that created a pool (e.g. a launchpad migration). For "swaps of token X" or "trades in pool Y" use pool_recent_trades, tx_trades, early_buyers or top_traders_by_token (resolve the pool with token_dex_venues); to keep one token within a wallet's records, pass mint.

FRESHNESS: records arrive with a delay — typically tens of minutes, at times several hours. A recent transaction may not be searchable yet — retry later instead of concluding it does not exist.

COST: WITH address → indexed lookup over that wallet's last 90 days (days); it can still time out when the service is busy — retry later, or lower days. WITHOUT address → scan of ALL Solana activity in since_time/before_time (default last 7 days, billions of records): it almost always times out, so give an address whenever you can; it also needs instruction or program (with neither it returns nothing). Page back with cursor: pass the Cursor value of the LAST row of a page — unlike before_block it never skips the other matches in that block.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "solana_find_instructions"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNoWith address only: how far back to search, in days (default 90, max 20000). The window ends at before_time (else today) and reaches `days` back from it; an explicit since_time overrides the lower edge. An empty or short page can simply mean the window ran out - raise days to search deeper.
mintNoKeep only records of this ONE token, by its mint address (base58, case-sensitive; native SOL = "-"). Works for any token, including new ones without a known symbol. A filter on the found records, not a search key - combine it with address. Empty = all tokens.
limitNoMax matching instruction records (newest first), 1-1000.
cursorNoExact paging cursor: pass the Cursor value of the LAST row of the previous page, unchanged, to get the next page. Prefer this over before_block, which skips the other matches sharing the last row's block. When set, before_block is ignored. Empty = first page.
formatNoShape of the returned data. "rows" (the default) returns one item per row. "columnar" returns a single item, {"columns":[...],"rows":[[value,...],...]}, naming the columns once and listing each row's values in that order; it is more compact for large results and carries the same values.rows
addressNoBase58 WALLET (32-44 characters) that sent or received value in the record (the owner, matched verbatim). A token mint, a token account or a pool / market address never matches its swaps or transfers (only the createAccount record that created it) - for a token's or pool's swaps use pool_recent_trades / tx_trades / early_buyers / top_traders_by_token. Much faster than a scan. Empty = scan all Solana activity in the time window (very heavy, usually times out); without an address, instruction or program is REQUIRED - with neither the result is empty.
programNoRestrict to one program: a decoded program name ("spl-token", "system", "stake", "Orca") or a base58 program id (the only way to select an undecoded program such as Raydium LaunchLab LanMV9sAd7wArD4vJFi2qDdfnVhFxYSUg6eADduJ3uj). Letters, digits, ".", "_" and "-" only. Matches Program OR Outer_Program, i.e. the executing program or the top-level one - never a program called in between. Empty = any program.
since_timeNoOnly matches at/after this UTC time (e.g. "2026-09-01 00:00:00"). Without address, empty defaults to the last 7 days.
before_timeNoOnly matches strictly before this UTC time (e.g. "2026-09-01 00:00:00"). Empty = no upper bound.
instructionNoDecoded method name as stored (see the list above, e.g. "merge", "mintTo", "transferChecked", "DecreaseLiquidity"); letters, digits and underscores only. Case-insensitive and underscore-insensitive ("transfer_checked" = "transferChecked"), but otherwise exact: "transfer" does NOT match "transferChecked" - token legs use either, so search both or leave this empty. Matched against Method (the executing program) OR Outer_Method (the top-level instruction). Undecoded programs (Raydium, pump.fun, Jupiter, ...) have no method names at all - use program with an empty instruction. Empty = any method.
before_blockNoCoarse upper bound — only matches with Block strictly below this. NOT a paging cursor. It skips every other match in that block and a busy block holds many, so page with cursor instead; before_block is ignored when cursor is set. 0 = no bound.
only_successfulNo1 (default) = only successful transactions; 0 = include failed ones.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / format
      Added value: +{
      +  "default": "rows",
      +  "description": "Shape of the returned data. \"rows\" (the default) returns one item per row. \"columnar\" returns a single item, {\"columns\":[...],\"rows\":[[value,...],...]}, naming the columns once and listing each row's values in that order; it is more compact for large results and carries the same values.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnly/non-destructive, and the description adds substantially more: ingestion lag of tens of minutes to hours (retry rather than conclude non-existence), the 90-day indexed window with address vs the near-always-timeout full scan without one, the two-level Program/Outer_Program model, and that intermediate programs are never recorded. This is real behavioral context an agent cannot infer from the structured fields.

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

Conciseness4/5

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

Long but front-loaded and organized under clear caps headers (WHAT IS SEARCHABLE, TWO LEVELS ONLY, FRESHNESS, COST). A few passages restate schema text, e.g. the cursor-vs-before_block warning appears both here and in two parameter descriptions, which is duplication against a 12-parameter schema.

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

Completeness5/5

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

Given 12 optional parameters, no output schema and no required fields, the description covers everything needed to call it correctly: what data exists, what is silently absent (Raydium/pump.fun/Jupiter methods), the unknown:<id> currency convention and raw base units, latency, cost and paging. The only gap, exact return field format, is partially addressed by the record enumeration.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema states only piecemeal: address must be an owner wallet (not a mint/pool, which only matches the createAccount record), without address either instruction or program is required, and instruction is exact so "transfer" does not match "transferChecked". Some overlap with the per-parameter text keeps it from a 5.

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

Purpose5/5

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

Opens with a specific verb + resource + scope ("FIND Solana transactions by program instruction... search one WALLET's value-moving records by decoded method name and/or program"), and names how it differs from solana_tx_transfers, pool_recent_trades and tx_trades. An agent can identify the tool and its output shape without opening the schema.

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

Usage Guidelines5/5

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

Explicit routing: use pool_recent_trades / tx_trades / early_buyers / top_traders_by_token for swaps of a token or trades in a pool, use mint to keep one token within a wallet's records, use program=<id> with empty instruction for undecoded DEXs. It also states when a search returns nothing (undecoded method names, address = pool).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.