coin-scout

Overview Schema Source Related Servers Discussions Admin

Get raw transaction

get_transaction_raw

Read-onlyIdempotent

Fetch a transaction's full raw JSON, including logs, inner instructions, compute units, and pre/post balances, to debug custom programs or failures when standard parsed results fall short.

Instructions

Full raw jsonParsed transaction including logMessages, inner instructions, compute units and pre/post balances. Use only when the enhanced parse in get_transactions is not enough (custom programs, failure debugging).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "signature": "<signature>"
    },
    "name": "get_transaction_raw"
  }
}

Input Schema

Name	Required	Default
`signature`	Yes
`commitment`	No	confirmed
`includeLogs`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.0.0-developmentOct 17, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered; the description adds real value by disclosing the shape of the payload (logs, inner instructions, compute units, balances). It stops short of noting cost/rate limits or the heaviness of a raw fetch, which matters for a tool meant to be used sparingly.

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

Conciseness5/5

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

Two tight sentences with the content summary front-loaded and the usage constraint second. Every clause carries information; nothing is padding.

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

Completeness4/5

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

With no output schema, the field list usefully describes what comes back, and the when-to-use rule is complete. The remaining gap is parameter guidance (commitment semantics), which an agent needs to invoke the tool correctly.

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

Parameters2/5

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

Schema description coverage is 0% and none of the three parameters are explained: 'commitment' (with its confirmed/finalized enum) and 'includeLogs' are never addressed. The mention of 'logMessages' only loosely implies the includeLogs default and adds no guidance on commitment levels, so the description fails to compensate for the coverage gap.

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?

States a specific verb and resource ('Full raw jsonParsed transaction') and enumerates the distinguishing payload contents (logMessages, inner instructions, compute units, pre/post balances). It explicitly separates itself from the sibling get_transactions, so an agent can pick between them without opening either 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?

Gives an explicit when-to-use rule ('Use only when the enhanced parse in get_transactions is not enough') plus the concrete conditions that select it (custom programs, failure debugging). Both the alternative and the exclusion criterion are named.

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