Ordinals data is scattered across inscriptions, runes, BRC-20 and sat ranges, each with its own shape, and answering something like what is in this wallet means hitting several of them. Having all of it behind one authenticated server with Zod-validated inputs turns that into one conversation. It reads only — nothing here signs or broadcasts a transaction — and the key you hand it is Ordiscan's, not a wallet's.
A read client for the Bitcoin ordinals ecosystem, connecting directly to `api.ordiscan.com` with no proxy in between. It covers what an address holds, what moved through a transaction, and the reference data behind inscriptions, collections, runes, BRC-20 tokens and rare sats. It runs as an HTTP stream server on port 1337.
- Address tools cover UTXOs, inscriptions, rune balances, BRC-20 balances and rare sats held by a Bitcoin address
- Activity tools track inscription, rune and BRC-20 transfers for an address
- Transaction tools return transaction info plus the inscriptions and runes that moved in it
- `ordiscan_inscription_info` returns detail on a single inscription; traits, list and transfer tools sit alongside it
- `ordiscan_rune_market` returns market information for a rune, next to a runes list and a name-availability check
- `ordiscan_brc20_info` returns token detail, with a BRC-20 list beside it
- `ordiscan_main` is the general-purpose entry point for rune information and status
An Ordiscan API key. Pass it as the `apiKey` parameter on a call, or set `ORDISCAN_API_KEY`; every tool sends it as `Authorization: Bearer <your-api-key>`. Build with `npm install` and `npm run build`, then `npm start` — the server listens on port 1337 and clients reach it at `/mcp`, locally or through a deployed URL. Rate limiting is handled by Ordiscan at their end, so your key's plan is what governs throughput.
One command plus a key — npx mcp-remote https://your-deployed-server.com/mcp, then supply credentials