RAVN

Prepare a signable Bitcoin transaction for a RAVN DEPOSIT

ravn_btc_prepare_send

Read-only

Turns a DEPOSIT-type ravn_execute result (depositAddress + depositAmount) into a ready-to-sign PSBT, so you don't have to write your own UTXO selection and fee-estimation code. Fetches your UTXOs and the current network fee rate from mempool.space (public, no auth). RAVN never sees or touches a private key — sign the returned PSBT with your own wallet and broadcast it yourself. Only one signer is ever needed (unlike PSBT flows that require coordinating signatures across multiple UTXO-holding wallets), because every RAVN BTC-source venue resolves to a plain single-recipient payment.

Input Schema

TableJSON Schema

Name	Required	Description
`network`	No
`toAddress`	Yes	depositAddress from ravn_execute
`amountSats`	Yes	depositAmount from ravn_execute, in satoshis
`fromAddress`	Yes	Your Bitcoin address holding the UTXOs to spend — native SegWit (bc1q…) or Taproot (bc1p…) only
`feeRateSatsPerVb`	No	Omit to use mempool.space's current halfHourFee estimate

TDQS

A4.4/5.0

Behavior5/5

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

The description discloses that it fetches UTXOs and fee rate from mempool.space without auth, never touches a private key, and expects the caller to sign and broadcast. These are meaningful behavioral details beyond the readOnlyHint/openWorldHint annotations and do not contradict them.

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?

Four sentences, each carrying distinct information: the transformation, the network/fee behavior, the security model, and the single-signer property. The main purpose is front-loaded with no filler.

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?

The description is comprehensive for selecting and calling the tool: it identifies inputs, external dependencies, fee behavior, and output type (PSBT). Because there is no output schema, the exact return encoding is not specified, but the PSBT outcome and next steps are clear enough.

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?

Schema description coverage is 80%, so the schema already explains most parameters. The description adds the upstream ravn_execute relationship, but much of that is also present in the schema descriptions (toAddress/amountSats are already labeled depositAddress/depositAmount from ravn_execute).

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 states a specific verb and resource: it turns a DEPOSIT-type ravn_execute result into a ready-to-sign PSBT. This clearly distinguishes the tool from the general ravn_execute/quote/status/health siblings and from manual UTXO/fee code.

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 says the tool is for use after a DEPOSIT-type ravn_execute and replaces hand-written UTXO selection and fee estimation. It also states the one-signer condition, but it does not explicitly enumerate when not to use the tool or name a sibling alternative.

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

All RAVN tools Inspect

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.3/5.0

Disambiguation5/5

Each tool maps to a clear lifecycle stage: health pre-checks routes, quote produces a token, execute turns it into a payload, btc_prepare_send handles a specific BTC deposit-to-PSBT step, and status polls the resulting swap. No two tools are likely to be confused.

Naming Consistency4/5

The core tools use a clean ravn_<verb> pattern: quote, execute, status, health. The outlier is ravn_btc_prepare_send, which front-loads the asset and combines two actions, breaking the verb-first pattern slightly.

Tool Count5/5

Five tools is a well-scoped size for a swap execution server. Each tool earns its place and covers a distinct part of the workflow without redundancy.

Completeness4/5

The core swap lifecycle is covered end-to-end: quote, execute, status, health, plus a BTC-specific helper for a common deposit flow. The main gap is the lack of an explicit tool for discovering supported chains/assets/venues, forcing agents to probe via ravn_quote.

Resources

Need Help?