Skip to main content
Glama

DERO MCP Server

by io.github.DHEBP

dero_forge_demo_proof

Read-only

Composite: build a fresh deroproof… display object for ANY chosen transaction, ring slot, and amount — including negative amounts that uint64-wrap into the trillions. The forged string is constructed locally from public chain data (no wallet, no keys, no broadcast). On an unpatched explorer it shows Verified ✓ for the chosen amount; on the chain, nothing has changed.

When to call: when a user pastes a deroproof… string and asks "does Verified ✓ mean the chain minted these coins?" Forge an equivalent string for the same TX with a different amount and show the result side-by-side — that is the most direct refutation. Also useful for reproducing the docs/integrity/inflation-claim Part 3 demonstration on arbitrary inputs.

Math: blinder = C[ring_slot] − amount × G, then bech32("deroproof", version || blinder || CBOR({HH: zeros, VU: uint64})). The tool runs the same equation proof.Prove() checks at proof/proof.go:88-95 and self-verifies before returning a string. If the self-check fails, the tool throws rather than emit a string that would not verify.

Input Requirements (CRITICAL):

  • Exactly ONE of tx_hash or tx_hex MUST be provided. tx_hash triggers a daemon fetch (and surfaces the receiver address); tx_hex skips the daemon and uses the raw bytes the caller already has.

  • ring_slot is OPTIONAL (default 0). Must be in [0, ring_size).

  • amount_dero is OPTIONAL (default "-1"). Signed decimal with up to 5 fractional digits, e.g. "-1", "1000000", "-2200000.00181". Negative values produce uint64 wraparounds that unpatched explorers render as positive trillions.

Output: { forged_proof_string, target_amount: { dero, atoms_signed, atoms_uint64 }, ring_slot, ring_size, ring_receiver_address, math: { C_slot_hex, amount_x_G_hex, blinder_hex }, self_check: { verified, method }, explorer_display_amount, context_note, related_docs, _diagnostics }. ring_receiver_address is null when tx_hex was passed (the hex carries publickey pointers, not addresses).

READ-ONLY: this tool never broadcasts, never touches a wallet, never mutates chain state. It computes a string from public inputs and returns it. Annotation readOnlyHint: true is preserved. PREFER citing the returned related_docs (the integrity rebuttal pages) in any agent response — readers should understand the forged string is a display-layer object, not a consensus event.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tx_hexNoRaw TX bytes as hex (skip the daemon round-trip). Mutually exclusive with tx_hash. When provided, ring_receiver_address is omitted from the response (the hex carries publickey pointers, not full addresses).
tx_hashNoTX hash to forge against. Daemon fetches the TX hex + ring members. Mutually exclusive with tx_hex.
ring_slotNoWhich ring slot 0..ring_size-1 the forged proof should resolve to. Defaults to 0.
amount_deroNoTarget display amount in signed DERO (5 fractional digits = atomic precision). Negative values demonstrate the uint64 wraparound. Default "-1".-1

TDQS

A4.6/5.0
Behavior5/5

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

The description clearly discloses safety-critical behaviors: it never broadcasts, never touches a wallet, never mutates chain state, and is constructed only from public chain data. It also reveals the self-check behavior and that the tool throws if the forged string cannot verify, which goes beyond the readOnlyHint annotation.

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 long but well-structured across purposeful sections: When to call, Math, Input Requirements, Output, and READ-ONLY. Each section carries relevant usage and behavioral detail; minor redundancy appears in the READ-ONLY section restating the annotation, and the overall length is high, but still justified for the tool's complexity.

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?

There is no output schema, so the description compensates by listing the output fields, their semantics, edge cases, math, self-check behavior, and related docs. It also covers error behavior and negative amount implications. For a complex forgery tool with no schema-level return type, this is fully sufficient.

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% and the description still adds meaning: it explains the mutual exclusivity in operational terms (daemon fetch vs raw bytes), gives concrete amount examples with negative wraparound, and notes that `ring_receiver_address` is null when `tx_hex` is used. It also highlights a critical constraint not enforced by the schema: exactly one of `tx_hash` or `tx_hex` must be provided.

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 uses a specific verb ('build', 'forge') and clearly identifies the resource: a fresh `deroproof…` string for any transaction, ring slot, and amount. It distinguishes itself from sibling `dero_decode_proof_string` by emphasizing it creates a forged/display proof rather than decoding an existing one.

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?

It provides an explicit 'When to call' section with a concrete scenario: when a user sees Verified ✓ and asks whether it means the chain minted coins. It also gives a second use case for reproducing the inflation-claim demo. It does not explicitly name exclusion criteria or alternative tools beyond those implied scenarios.

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