Skip to main content
Glama

get_transaction_status

Read-onlyIdempotent

Polls a transaction's final status from the blockchain. Returns pending, success, failed, or dropped—detecting unlandable Solana txs via durable nonce or block height.

Instructions

Poll a transaction's status via the chain's RPC (EVM / Solana) or TronGrid (TRON). Returns pending / success / failed, plus 'dropped' on Solana when the tx is mathematically unable to land. Pass chain='tron' with the bare hex txID for TRON; chain='solana' with the base58 signature for Solana. For Solana, ALSO pass whichever drop-detection field send_transaction returned: (a) durableNonce for nearly every send (native/SPL sends, nonce_close, jupiter_swap, all marginfi_* actions) — the tool reads the on-chain nonce account and reports 'dropped' if it rotated past the baked value; or (b) lastValidBlockHeight for legacy-blockhash txs (currently just nonce_init) — reports 'dropped' if current block height is past. Without either field the tool reports 'pending' forever for dropped txs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainYesEVM chain, 'tron', 'solana', or 'bitcoin'.
txHashYesTransaction identifier. EVM: 32-byte hex (0x-prefixed or bare). TRON: 32-byte bare hex. Solana: 64-byte signature as base58 (86–88 chars). Bitcoin: 32-byte bare hex. All four forms are accepted.
lastValidBlockHeightNoSolana only, legacy-blockhash txs (currently just `nonce_init`). Block-height ceiling for the tx's baked blockhash — returned by send_transaction for such txs. When supplied and `getSignatureStatuses` returns null, the poller compares against current block height and reports `dropped` if the window has passed. Omit for EVM / TRON; ignored on those chains. For durable-nonce Solana txs (every send this server builds except nonce_init), use `durableNonce` instead — it's authoritative.
durableNonceNoSolana only, durable-nonce txs (native_send, spl_send, nonce_close, jupiter_swap, all marginfi_* actions). Returned by send_transaction on these flows. When supplied and `getSignatureStatuses` returns null, the poller reads the on-chain nonce account: if the nonce rotated past `nonceValue` (or the account was closed), the tx can never land and is reported as `dropped` with diagnostic fields `nonceAccount` / `bakedNonce` / `currentNonce`. Without this field the poller reports `pending` forever for dropped durable-nonce txs — a known Phase 2 UX gap.
Behavior5/5

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

The description adds significant behavioral context beyond the annotations (readOnlyHint, destructiveHint, idempotentHint). It details the drop-detection logic for Solana (durableNonce vs lastValidBlockHeight), the behavior when fields are missing, and the diagnostic fields returned. No contradictions with annotations.

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?

The description is lengthy due to the complexity of multi-chain and drop-detection logic, but every sentence serves a purpose. The main action is front-loaded. A minor trim could improve conciseness, but the detail is necessary for correct usage.

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?

Despite no output schema, the description thoroughly covers return values (pending/success/failed/dropped) and diagnostic fields. For a complex tool with 4 parameters and multi-chain behavior, the description is complete and leaves no significant gaps.

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

Parameters5/5

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

Schema coverage is 100%, and the description adds valuable meaning beyond the schema. It explains the specific usage for each chain (e.g., 'chain='tron' with bare hex txID'), the condition for Solana parameters, and the fallout of omitting them. This enhances the schema's definitions substantively.

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?

The description clearly states it polls a transaction's status from multiple chains (EVM, Solana, Tron, Bitcoin) and returns specific states (pending/success/failed/dropped). It uses specific verbs and resources, distinguishing it from sibling tools like send_transaction. The purpose is unambiguous.

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

Usage Guidelines4/5

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

The description provides detailed contextual guidance on when and how to use each parameter, especially the Solana drop-detection fields. It explains the consequences of omitting fields ('reports pending forever'). However, it does not explicitly state when not to use the tool or list alternative tools, though the context implies it's for post-send polling.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/szhygulin/vaultpilot-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server