Sign and submit pre-built unsigned transactions through a configured cardano MCP server. This is a high-risk operation — the MCP server has no server-side approval gate and will sign+submit any CBOR passed to it. Safety depends entirely on the preview-confirm flow defined below.
When to use
User has a pre-built unsigned transaction (CBOR hex) from a dApp API, MeshTxBuilder, or cardano-cli transaction build.
User wants to sign and submit that transaction via their MCP-configured wallet.
A configured cardano MCP server is available.
When NOT to use
User needs to build a transaction — use cardano-cli-transactions, meshjs-cardano, or koios-agent-wallet. The MCP server cannot construct transactions.
No cardano MCP server is configured — use koios-agent-wallet (sign-submit mode) or cardano-cli transaction sign + submit.
User needs testnet submission — current integration assumes mainnet unless testnet support is explicitly validated.
The transaction CBOR cannot be summarized — refuse to submit (see operating rules).
Operating rules (MUST follow — no exceptions)
Rule 1: Never submit without a structured preview
Before calling submit_transaction, you MUST present a structured preview to the user containing ALL of the following fields:
If you cannot produce this preview (e.g., you cannot decode the CBOR, or the transaction structure is opaque), you MUST refuse to submit and explain why.
Rule 2: Require unambiguous confirmation
The user must respond with a clear affirmative tied to the preview. Accept: "yes", "confirm", "submit it", "go ahead". Reject: vague responses like "sure", "whatever", "I guess", or any response that doesn't clearly reference the transaction. If ambiguous, ask again.
Rule 3: One transaction per confirmation
Each submit_transaction call requires its own preview-confirm cycle. Never batch or auto-submit.
Rule 4: Fail closed on uncertainty
Cannot determine the network? Refuse.
Cannot decode the CBOR? Refuse.
Cannot identify the source wallet? Refuse.
Unsure if MCP is configured for the right network? Refuse.
State what you cannot verify and suggest the user use CLI or Koios skills with explicit network flags instead.
Rule 5: Never ask for seed phrases or keys
The MCP server handles signing internally. Never prompt for mnemonics, private keys, or signing keys.
Rule 6: Network assumption
Current integration assumes mainnet unless testnet support is explicitly validated against the configured MCP server. If the user states they are on testnet, do NOT use this skill — route to koios-agent-wallet or cardano-cli-transactions-operator with explicit network flags.
MCP tool
submit_transaction
Sign and submit an unsigned transaction from the connected wallet.
The seed phrase never leaves the MCP server process. The agent never sees key material. Safety depends on the preview-confirm flow in this skill and the user's own review.
References
shared/mcp-provider.md
shared/PRINCIPLES.md
cardano-cli-transactions (CLI tx building guidance)
