Skip to main content
Glama

Investigate transaction

investigate_transaction
Read-onlyIdempotent

Analyze a single Solana transaction to trace SOL/token deltas per account, screen involved mints for rug risk, and profile the fee payer during fraud investigations.

Instructions

Deep dive on one signature: enhanced parse, net SOL/token delta per account, every mint involved screened for rug risk, and a profile of the fee payer. Use when a single transaction is the starting point of an investigation.

Input Schema

NameRequiredDescriptionDefault
signatureYes
screenMintsNoRun analyze_token on each mint involved
profileFeePayerNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.0-development

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld. The description adds real behavioral context: it implicitly runs analyze_token per mint and profiles the fee payer, signaling an expensive multi-step analysis rather than a single lookup. It omits cost/latency caveats, so not a 5.

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?

Two sentences, front-loaded with the analysis scope and ending with the usage trigger. Dense but every clause earns its place; the feature list is a touch run-on but not padded.

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 description carries the return-value burden and does so at a high level by naming the four analysis components. Combined with annotations covering safety and partial param coverage, an agent has enough to invoke it correctly, though the exact response shape and cost are unspecified.

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 low (33%), so the description must compensate, and it does: 'every mint involved screened for rug risk' and 'a profile of the fee payer' map directly to the screenMints and profileFeePayer toggles. The signature param is self-evident, so the main ambiguity is resolved.

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+resource ('Deep dive on one signature') and enumerates concrete outputs: enhanced parse, net SOL/token delta per account, mint rug screening, and fee-payer profiling. This clearly distinguishes it from raw/list siblings like get_transaction_raw and get_transactions.

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?

'Use when a single transaction is the starting point of an investigation' gives a clear triggering condition. It does not name a cheaper alternative (e.g. get_transaction_raw) or say when NOT to use it, so it stops short of full when/when-not guidance.

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