Reading a raw transaction or a BOLT11 invoice in plain terms — what it pays, to whom, under what expiry — is the kind of question that otherwise means finding a decoder website, and here it happens where the conversation already is, with no credentials involved. Treat the payment tool separately: it moves real funds from the LNBits wallet whose admin key you supplied, so decode_invoice first and keep the admin key out of any configuration you would not trust with the balance.
A small Bitcoin and Lightning toolkit. Key generation, address validation and transaction decoding happen locally; block and transaction lookups query the chain; Lightning payment goes through an LNBits wallet you configure.
- generate_key produces a new key pair — address, public key and private key in WIF form
- validate_address checks whether a Bitcoin address is well formed
- decode_tx parses a raw transaction hex into readable detail
- get_latest_block returns the most recent block: hash, height, timestamp and transaction count
- get_transaction fetches a transaction's details by txid
- decode_invoice parses a BOLT11 Lightning invoice into human-readable terms — what it asks for and on what conditions
- pay_invoice pays a Lightning invoice from the configured LNBits wallet
Nothing for the Bitcoin side — key generation, validation, decoding and chain lookups need no account. It runs as npx -y bitcoin-mcp@latest. Lightning is the part that takes credentials: an LNBits account and wallet, configured with lnbitsUrl plus lnbitsAdminKey for making payments and lnbitsReadKey for wallet information, both found under API info in LNBits. Without them the Lightning payment tool has nothing to pay from.
One command plus a key — npx -y bitcoin-mcp@latest, then supply credentials