The Bitcoin Adviser

Compare selling Bitcoin with borrowing against it

borrow_vs_sell

Read-onlyIdempotent

Illustrates the liquidity from selling an amount of Bitcoin after tax, against borrowing on it as collateral, and what each leaves at a later price. Deterministic; the same model as the live Borrowing Against Bitcoin explorer, in USD. mode btc_to_btc borrows BTC at ltvPct (default 95%); the lender keeps a 5% fee from the collateral, so the rest is retained; fiat_loan borrows USD at ltvPct (default 50%) with simple interest (default 8% a year for 1 year), and returns a liquidation price where the loan reaches 80% of the collateral's value. Tax is a flat rate on the whole sale value, from taxRatePct or the region's default (us 20%, au 45%, illustrative only). horizon sets the later price as a multiple of spot: flat (x1), up50 (x1.5), up100 (x2), stress30 (x0.7), stress50 (x0.5); never a forecast. Stress rows at 30% and 50% below spot are always included. A negative or non-finite termYears is rejected. Other out-of-range values are clamped as the page clamps them, and the result echoes what was used. btcPrice is a spot price in USD supplied by the caller (btcPriceUsd is accepted as an alias). Without it the server's cached USD market reference is used, labelled live, or a fixed illustrative price of 100000 USD when that reference is unavailable. The illustrative price is not a market quotation. It names no lender, does not assess suitability or eligibility, and recommends neither path.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "borrow_vs_sell"
  }
}

Input Schema

Name	Required	Description
`mode`	No
`ltvPct`	No
`horizon`	No
`btcPrice`	No
`btcAmount`	No
`taxRegion`	No
`termYears`	No
`taxRatePct`	No
`btcPriceUsd`	No	Alias of btcPrice, in USD.
`interestRatePct`	No

Output Schema

Name	Required	Description	Default
`kind`	Yes
`sell`	Yes
`borrow`	Yes
`inputs`	Yes
`stress`	Yes
`summary`	Yes
`nextStep`	Yes
`disclaimer`	Yes
`assumptions`	Yes
`referencePrice`	Yes
`horizonPriceUsd`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so safety is covered; the description goes well beyond that with deterministic-output guarantees, clamping of out-of-range values, rejection of negative or non-finite termYears, always-included stress rows, and an echoed result showing what was used. It also discloses the data provenance chain for the BTC price (caller-supplied, cached live reference, or fixed illustrative 100000 USD) and warns that the illustrative price is not a market quotation.

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

Conciseness3/5

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

The purpose is front-loaded, but the remainder is a single dense block of semicolon-chained clauses covering defaults, clamping, provenance and disclaimers with no structural separation. Every fact is arguably useful, yet the run-on packing makes it hard to scan for the specific parameter an agent needs.

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?

For a zero-required-parameter, ten-property, closed-world modelling tool with 10% schema coverage, this is close to complete: behaviour, defaults, edge-case handling, price provenance and scope limits are all stated. An output schema exists, so the absence of return-value prose is not a gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 10%, so the description must carry the load, and it largely does: it explains both mode values with their default ltvPct (95% / 50%), the lender's 5% collateral fee, the 80% liquidation threshold, the 8%/1-year simple-interest default, all five horizon enum values as price multiples, the taxRatePct/taxRegion defaults (us 20%, au 45%), the btcPrice/btcPriceUsd aliasing and fallback, and termYears validation. Only btcAmount is left without units or a default, a small residual gap against the rest.

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?

Opens with a concrete verb and two named resources: 'Illustrates the liquidity from selling an amount of Bitcoin after tax, against borrowing on it as collateral, and what each leaves at a later price.' That is enough for an agent to distinguish this modelling tool from siblings like compare_growth or choose_path, which compute different comparisons.

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?

Usage context is clear: it is a deterministic model matching the live 'Borrowing Against Bitcoin' explorer, in USD, and it explicitly refuses to forecast, recommend a path, or assess suitability. What is missing is any explicit routing advice naming when another sibling (e.g. compare_growth, assess_risk) should be chosen instead, or when a caller should skip this tool entirely.

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

All The Bitcoin Adviser tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?