Skip to main content
Glama
0xfreak0

sui-analytics-mcp

by 0xfreak0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_transaction

Retrieve any Sui transaction by its digest and get sender, status, gas, balance changes, plus protocol-aware decoded actions and event fields—no GraphQL needed.

Instructions

Get a Sui transaction by its digest. Returns sender, status, gas, balance changes, protocol-aware decoded actions (e.g. 'swap on Cetus', 'deposit on Suilend'), and events WITH their decoded fields — so there is no need to hand-write GraphQL to read an event's values. Protocols are identified from the events as well as the Move calls, which matters when a transaction calls an obfuscated wrapper: protocols_from_events_only marks that case.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
digestYesTransaction digest (Base58)
networkNoWhich Sui network to run this call against: 'mainnet' (default), 'testnet', or 'devnet'. Set this per-call — different tool calls in the same session can target different networks (e.g. to compare a value on testnet against mainnet).
max_event_field_bytesNoOptional byte cap on decoded event fields. UNSET BY DEFAULT: every event comes back with its fields, because an investigation must not be silently working from a subset. Set this only when you knowingly want to bound the payload — anything skipped is reported — or set 0 to skip decoding entirely.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.12.1
    • addedInput schema / properties / max_event_field_bytes
      Added value: +{
+  "description": "Optional byte cap on decoded event fields. UNSET BY DEFAULT: every event comes back with its fields, because an investigation must not be silently working from a subset. Set this only when you knowingly want to bound the payload — anything skipped is reported — or set 0 to skip decoding entirely.",
+  "maximum": 500000,
+  "minimum": 0,
+  "type": "integer"
+}
  2. First observedv1.5.0

TDQS

A3.9/5.0
Behavior4/5

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

No annotations are provided, so the description carries the behavioral disclosure burden. It is transparent about returned fields, decoded event values, and the protocol-identification nuance for obfuscated wrappers, plus the default behavior for max_event_field_bytes is covered in the schema. It does not describe not-found handling or errors, but the disclosed behavior is material and specific enough for an agent to understand what happens when the tool is called.

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 purpose is front-loaded and the description is information-dense, explaining why decoded events matter and flagging the obfuscated-wrapper edge case. It is slightly long, but every clause adds value and there is no filler; the examples such as 'swap on Cetus' make the behavior concrete.

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?

Given no output schema and no annotations, the description does a strong job of covering return contents and a subtle behavioral edge case, which is enough for a read-style tool. It could also specify behavior for missing digests or error responses and clarify where the `protocols_from_events_only` marker appears, but nothing essential for invoking with a digest is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already fully documents digest, network, and max_event_field_bytes. The description adds little parameter-specific meaning beyond contextualizing decoded event fields; it mostly reinforces schema guidance. Baseline 3 is appropriate since the structured schema does the heavy lifting.

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 and resource: 'Get a Sui transaction by its digest.' It goes beyond a generic getter by enumerating the exact payload — sender, status, gas, balance changes, decoded events and protocol-aware actions — and 'by its digest' clearly separates it from sibling listing/query tools like query_transactions 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 Guidelines3/5

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

The description implies the tool is for fetching a single transaction when the caller already has a digest, and it communicates the value of getting decoded event fields without hand-writing GraphQL. However, it never explicitly states when to prefer this over query_transactions/get_transactions, nor does it give exclusions, so the usage guidance is implied rather than explicit.

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

Deploy Server

Other Tools