Skip to main content
Glama

DERO MCP Server

by io.github.DHEBP

trace_transaction_with_context

Read-only

Composite: look up a DERO transaction by hash, classify its confirmation status (confirmed | mempool | unknown) and kind (sc_install | transfer_or_invocation | coinbase | unknown), extract the SC surface inline when the tx is a contract install, and stitch the right DERO tx + DVM docs pages as citations.

When to call: as the FIRST step when investigating any tx by hash — the user asks "what is this tx", "is this confirmed", "what contract did this deploy", or "what does this tx do". PREFER this over chaining dero_get_transaction with dero_get_sc yourself: for SC INSTALL txs the composite already extracts the deployed function surface inline (no second RPC needed because the source is embedded in the tx record), classifies the kind so the agent does not have to inspect the raw shape, and protects against the "empty record" failure mode by surfacing structured TX_NOT_FOUND when the daemon does not know the hash.

Input Requirements:

  • tx_hash is REQUIRED. Must be 64 hex chars.

  • decode is OPTIONAL (default true). Pass false to ask the daemon to skip the JSON-decoded view (raw hex still comes back; the field hint that the binary is available).

  • include_sc_context is OPTIONAL (default true). Set false to skip the inline extractScSurface call for SC install txs (useful when you only need confirmation / ring info).

Output: { tx_hash, confirmation: { status, block_height, valid_block, invalid_blocks, in_pool }, kind, ring: { groups, first_group_size }, reward, signer_visible, native_balance, sc_install: { scid, surface, raw_code_length, has_code } | null, raw_tx_hex_length, narrative, related_docs, _diagnostics }. sc_install is non-null ONLY when the tx is a contract install AND the surface extractor produced something (tx_hash IS the resulting SCID in that case). SC invocation arg decoding is NOT performed — that requires walking the binary tx blob with the DERO tx codec, which is not bundled in this MCP. The composite surfaces raw_tx_hex_length so the agent knows the binary is available via dero_get_transaction. On unknown hash the daemon returns an empty record and the composite returns a structured _meta.error with code TX_NOT_FOUND.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
decodeNoPass decode_as_json=1 to the daemon. Default true. Decoded JSON view is informational; the raw hex always comes back.
tx_hashYes64-char hex transaction hash
include_sc_contextNoWhen true (default), runs the SC-install surface extraction inline when the tx contains contract code. SC invocation arg decoding is NOT performed in either mode; see module docs.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare read-only, non-destructive. Description adds the empty-record failure mode (TX_NOT_FOUND), clarifies SC invocation arg decoding is NOT performed, and tells the agent the raw hex is still available. Very transparent about boundaries.

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 with purpose and when-to-call. Every sentence adds context (failure modes, parameter rationale, output details). Slight redundancy (SC-doc notation appears twice) but overall efficient.

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?

Complex composite tool with no output schema, but description documents output structure, failure modes, defaults, and limitations thoroughly. Agent has everything needed to decide when and how to call.

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 baseline is 3. The description adds usage semantics for decode (informational view, raw hex still available) and include_sc_context (skip for performance), which goes beyond the schema. So it's a 4.

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?

Description opens with a precise composite action: 'look up a DERO transaction by hash, classify its confirmation status... extract the SC surface inline... stitch docs pages as citations.' It clearly distinguishes from chained alternatives by naming the exact tool pair it replaces. Users know exactly what this tool does.

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 'When to call' section states use as FIRST step for tx-hash queries. It also explains when NOT to use the composite and to prefer the chained approach for non-install txs. This is ideal guidance.

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

All DERO MCP Server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose, with detailed descriptions that specify when to call it and how it differs from similar tools. Composite tools are well-defined, overlapping concerns are minimized.

Naming Consistency4/5

Tool names follow a general pattern: 'dero_' for core daemon RPC wrappers, 'tela_' for TELA-specific composites, and descriptive names for other composites. While mostly consistent, there are exceptions like 'audit_chain_artifact_claim' and 'dero_durl_to_scid' breaking the pattern slightly.

Tool Count4/5

With 32 tools, the server is comprehensive but slightly heavy. However, each tool serves a specific need in the DERO ecosystem, covering chain queries, docs, TELA, and composite analyses. The count is justifiable given the domain breadth.

Completeness4/5

The tool set covers core chain operations, documentation, TELA app lifecycle, and common analytical tasks. Minor gaps exist, such as lack of wallet interaction tools or transaction submission, but these are outside the apparent read-only/analysis scope.

Resources