Skip to main content
Glama

Unsigned stake and vote delegation transaction (nothing is signed or sent)

build_delegation_transaction
Read-onlyIdempotent

Build an unsigned Cardano transaction that delegates a wallet's stake to a pool and/or its voting power to a DRep (or to "abstain" / "no-confidence"), for a wallet that signs for itself. Give the wallet's base address (or $handle) and at least one of pool and drep. Returns the transaction as CBOR hex with its hash, the fee and deposit (the refundable stake-key deposit, currently 2 ADA, only when the stake key is not registered yet), the certificates in plain words, the inputs and the single output that returns everything to the wallet, a read-back of the transaction decoded independently of the builder, the cost worked out from the transaction itself (cost), warnings and how to sign and submit it. Both the payment key and the stake key must sign. Refuses when the pool is unknown or retiring, the DRep is unknown or retired, the wallet already delegates there, the address is an enterprise or script address, or there is not enough ADA. Realtap never signs, holds keys or submits: nothing happens until the owner of the address signs and submits it. Call it only when that owner asked to stake or delegate; check the pool or DRep first with get_stake_pool or get_drep. Limited to a few calls per minute.

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": {
      "address": "<address>"
    },
    "name": "build_delegation_transaction"
  }
}

Input Schema

NameRequiredDescriptionDefault
drepNoDRep to delegate voting power to: a drep1… id (CIP-129 or legacy), "abstain" (always abstain) or "no-confidence" (always no confidence). Omit to leave the voting delegation as it is.
poolNoStake pool to delegate the stake to: a pool1… id or the 56-character hex of its key hash. Omit to leave the stake delegation as it is.
addressYesThe signer's mainnet base address (addr1…, 103 characters: payment and stake part) or a $handle that resolves to one. Enterprise, script and stake1… addresses cannot delegate.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover safety (readOnly, idempotent, non-destructive) but the description adds substantial context beyond them: the refundable 2 ADA stake-key deposit condition, that both payment and stake keys must sign, that nothing is signed/held/submitted, and a rate limit of a few calls per minute — exactly the kind of operational disclosure annotations cannot carry.

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?

Purpose is front-loaded and the block is dense with useful facts — return payload, refusal cases, signing requirements, rate limit — so nearly every clause earns its place. It is nonetheless a single very long paragraph that could be broken into shorter structured sentences without losing content.

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?

No output schema exists, but the description fully explains the return payload (CBOR hex, hash, fee, deposit, certificates in words, inputs and single change output, independent read-back, cost, warnings, sign/submit instructions) and the preconditions. Nothing an agent needs to invoke or interpret results is missing.

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 the schema already documents each field's format. The description adds real value by stating the either/or rule ('at least one of pool and drep'), the address-or-$handle form, and the consequence of omitting pool/drep (leaves existing delegation as-is) even though the schema also notes the omit behavior.

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 (build) and resource (unsigned Cardano delegation transaction) with precise scope: stake to a pool and/or voting power to a DRep. It distinguishes itself from get_stake_pool and get_drep by casting those as pre-checks rather than builders.

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?

Explicitly says 'Call it only when that owner asked to stake or delegate' and instructs to check the pool or DRep first with get_stake_pool or get_drep. It also enumerates refusal conditions (unknown/retiring pool, retired DRep, already delegated, enterprise/script address, insufficient ADA), giving clear when-not guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources