Skip to main content
Glama

finalize_btc_psbt

DestructiveIdempotent

Finalize a fully signed multi-sig PSBT by verifying each input meets its signature threshold, then extract the broadcast-ready transaction hex. Optionally broadcast it to get the txid.

Instructions

Finalize a fully-signed multi-sig PSBT (typically the output of combine_btc_psbts once the threshold is met) and extract the broadcast-ready tx hex. Refuses with a per-input breakdown when any input is below its threshold (e.g. "input 0: 1/2 signatures"). Pass broadcast: true to send via the configured indexer in the same call — returns broadcastedTxid on success. Pass broadcast: false (default) when the caller wants to inspect the hex first or broadcast through a different relay. No device touch.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
psbtBase64YesBase64-encoded PSBT v0 with all required signatures spliced in (typically via `combine_btc_psbts`). Refused with a per-input breakdown when any input is below its threshold (e.g. 1/2 sigs).
broadcastNoWhen true, broadcasts the finalized tx via the configured indexer and returns `broadcastedTxid` alongside `txid`. When false (default), only returns the tx hex — the caller decides when/where to broadcast.
Behavior4/5

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

Beyond annotations (destructiveHint=true, idempotentHint=true), the description adds valuable behavioral details: the per-input breakdown on refusal, the broadcast option affecting returned fields, and the note about no device touch. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is composed of three compact, front-loaded sentences. Each sentence earns its place: purpose, refusal behavior, and broadcast options. No fluff.

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, the description adequately explains returns: tx hex and optionally broadcastedTxid. It covers key behaviors and workflow. Minor gap: it doesn't explicitly mention returning txid for the non-broadcast case, but the intent is clear.

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?

The input schema already covers both parameters with descriptions (100% coverage). The description repeats some schema info but adds context about refusal and broadcast behavior. Baseline 3 is appropriate since the schema carries the parameter meaning.

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 clearly states the verb 'Finalize' and the resource 'fully-signed multi-sig PSBT', explicitly mentioning it extracts the broadcast-ready tx hex. It distinguishes from sibling tools like combine_btc_psbts and sign_btc_multisig_psbt by specifying its typical input and refusal behavior.

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?

The description provides context on when to broadcast (via the `broadcast` flag) and explains the refusal behavior when inputs are below threshold. However, it does not explicitly list alternatives or contraindications (e.g., when to use sign_btc_multisig_psbt instead), though mentioning combine_btc_psbts as typical input implies a workflow.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/szhygulin/vaultpilot-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server