Skip to main content
Glama
szhygulin

recon-crypto-mcp

by szhygulin
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

pair_ledger_btc

Idempotent

Enumerate Bitcoin addresses (legacy, segwit, native segwit, taproot) from a connected Ledger device via USB, scanning receive and change chains with BIP44 gap-limit logic.

Instructions

Pair the host's directly-connected Ledger device for Bitcoin signing. REQUIREMENTS: Ledger plugged in over USB, device unlocked, the 'Bitcoin' app open on-screen. Ledger Live's WalletConnect relay does NOT expose bip122 accounts to dApps, so Bitcoin signing goes over USB HID via @ledgerhq/hw-app-btc (same USB path as Solana / TRON). ONE CALL ENUMERATES ALL FOUR ADDRESS TYPES for the requested accountIndex (default 0): legacy P2PKH (44'/0'/<n>'/0/0 → 1...), P2SH-wrapped segwit (49'/0'/<n>'/0/0 → 3...), native segwit P2WPKH (84'/0'/<n>'/0/0 → bc1q...), and taproot P2TR (86'/0'/<n>'/0/0 → bc1p...). All four are cached so get_ledger_status can report them under the bitcoin: [...] section. Call again with a different accountIndex to expose additional accounts. Read-only on the device — the Ledger BTC app does not prompt during getWalletPublicKey by default. Phase 1 is mainnet-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
accountIndexNoLedger Bitcoin account slot. One call enumerates ALL FOUR address types for the given index (legacy at `44'/0'/<n>'/...`, p2sh-segwit at `49'/0'/<n>'/...`, native segwit at `84'/0'/<n>'/...`, taproot at `86'/0'/<n>'/...`) AND walks both the receive (`/0/i`) and change (`/1/i`) chains using BIP44 gap-limit scanning so a previously-used wallet's later-index funds aren't missed. 0 = first Bitcoin account, 1 = second, etc. Omit for the default (index 0). Call again with a different index to expose more accounts; calling with the same index refreshes the cache.
gapLimitNoBIP44 gap limit — stop walking each (type, chain) after this many consecutive addresses with zero on-chain history. Default 20 (matches Electrum / Sparrow / Trezor Suite / Ledger Live). Lower values speed the scan up but risk missing funds across larger gaps; raise it for wallets that may have skipped indices. Capped at 100.

Tool Definition Quality

A4.4/5.0
Behavior3/5

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

Description adds significant behavioral details (enumerates four address types, caching, mainnet-only, gap-limit scanning) beyond annotations. However, there is a contradiction: annotations set readOnlyHint=false while description claims 'Read-only on the device,' which may mislead the agent about side effects. IdempotentHint=true is consistent.

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

Conciseness4/5

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

The description is front-loaded with purpose and requirements, then details address types and caching. It is slightly long but every sentence adds value. Minor verbosity in listing sibling tools and phase info, but overall well-structured.

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?

Given the two optional parameters and no output schema, the description fully explains what the tool does, how it works (address derivation, caching), and constraints (mainnet-only, device requirements). No gaps remain for an agent to understand its usage.

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

Parameters4/5

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

Input schema has 100% coverage with detailed descriptions for both parameters. The description further adds context by explaining that a single call enumerates all four address types and walks both chains, and that gap-limit scanning is used. This enriches the schema information.

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 tool pairs a directly-connected Ledger device for Bitcoin signing, distinguishing it from sibling tools like pair_ledger_live (which uses WalletConnect) and pair_ledger_ltc (Litecoin). Verb+resource is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit requirements are provided (USB plugged, device unlocked, Bitcoin app open). It explains when not to use (Ledger Live WalletConnect relay doesn't expose bip122 accounts) and gives context on alternative pairing methods. Instructions for calling with different accountIndex are clear.

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/recon-crypto-mcp'

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