Stablecoin Scanner (StableScan) vs Tonnode MCP
A side-by-side look at the Stablecoin Scanner (StableScan) and Tonnode MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Stablecoin Scanner (StableScan) for finance & fintech work over a hosted endpoint; choose Tonnode MCP for finance & fintech as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Stablecoin Scanner (StableScan) when
- You need dedicated capabilities in the Finance & Fintech domain.
- You prefer a remote HTTP/SSE transport.
- Its auth model fits you: No auth required.
- You want tools like
get_address_approvals, get_address_compliance, get_address_exposure.
Choose Tonnode MCP when
- You need dedicated capabilities in the Finance & Fintech domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
- You want tools like
get_masterchain_info, get_balance, get_account_state.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Finance & Fintech | Finance & Fintech |
| Quality signal | 56/100 · Good | 67/100 · Great |
| Install command | Confirmed | Confirmed |
| Transport | Remote HTTP/SSE | Local subprocess (stdio) |
| Auth | No auth required | No auth required |
| Pricing | Free | Free |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | — | 27 |
| Directory activity | 0 views 0 installs 0 upvotes | 4 views 0 installs 0 upvotes |
| Tools | 8 | 16 |
| Full listing | View Stablecoin Scanner (StableScan) | View Tonnode MCP |
Tools & capabilities
Stablecoin Scanner (StableScan) tools 8
get_address_approvalsOpen ERC-20 and Permit2 allowances one address has granted on one chain, one row per spender and token with the raw value, unlimited/oversized/old flags, spender_class and a band (critical|high|low|expired|none): unlimited to a flagged or unknown spender is the main drain vector, a known service spender (DEX router, Permit2) is normal, an expired Permit2 sub-allowance reads 'expired'. Use it when the question is what a wallet has approved and who could pull its stablecoins. Not for a risk tier — the band is informational and never moves get_address_risk. Not for issuer freezes: get_address_compliance. Not for taint: get_address_exposure. address is the allowance owner (the granter), never the spender. Heavy read: under load it answers busy or timeout — retry with backoff. No auth; 1200 requests/min shared by all tools. A heuristic band over decoded on-chain Approval facts, not an AML or legal determination.get_address_complianceIssuer freeze/seize facts for one address on one chain, plus the OFAC SDN flag: freeze[] (one row per freeze-capable stablecoin, status frozen|seized|clear|unknown, with frozen_usd6 = the balance locked now where it was read), not_freezable[] (stablecoins whose issuer cannot freeze on this chain, e.g. the Binance-Peg wrappers on BNB Chain — enforcement is off-chain), frozen_elsewhere[] (the same address bytes under a standing freeze on another indexed chain; EVM and Tron share them, Solana never) and freeze_proposals[] (issuer multisig proposals naming the address, USDT on Ethereum and Tron: executed ones, pending only where the operator publishes them). Use it when the question is whether an issuer or OFAC acted on this address, or how much is frozen. Not for a risk tier: get_address_risk. Not for taint distance: get_address_exposure. Not for when the OFAC list was refreshed: get_sanctions_status. Decoded on-chain issuer acts with provenance, no heuristics. 'unknown' means no act names the address and that pair's freeze history is not fully backfilled yet — absence of evidence is not 'not frozen'; an empty frozen_elsewhere[] or freeze_proposals[] means none in what is indexed, not clean everywhere. Each chain is its own issuer act: pass chain to ask Ethereum or Tron about the same bytes, chains_with_data says where. Heavy read: under load it answers busy or timeout — retry with backoff. No auth; 1200 requests/min shared by all tools. Not an identity, AML or legal determination.get_address_exposureTaint exposure of one address on one chain: a bounded backward walk over the value graph to the nearest OFAC-sanctioned or hack/drainer/mixer root, answered as a class (sanctioned|direct|indirect|negligible|unknown|none), the nearest hop and a value-proportional haircut fraction. Use it to explain how closely an address is tied to a sanctioned or hack root and by how much value. Not for one go/no-go tier — get_address_risk already includes this walk. Not for the counterparties themselves or a chosen depth, token or window: get_wallet_graph_walk. Not for issuer freezes: get_address_compliance. 'unknown' means the walk did not complete — OFAC list unloaded, time_budget, frontier_cap, Solana coverage pending or partial, short history, or no hack/drainer/mixer label loaded for this chain — never a false 'none'; incomplete_reasons names which (time_budget may complete at a quieter moment, frontier_cap repeats). Depth is fixed at 3 hops and the walk never crosses chains: ask again with chain set for each network in chains_with_data. A verdict is reused for up to 60 s (10 s after a time_budget cut). Heavy read: under load it answers busy or timeout — retry with backoff. No auth; 1200 requests/min shared by all tools. A heuristic signal, not an AML or legal determination.get_address_riskUnified risk tier for one address on one chain — unknown|none|low|medium|high|severe — from decoded facts (OFAC listing, issuer freeze/seize on this chain, exposure to a sanctioned or hack root) and attributed labels with provenance (labels alone cap at medium; a lone-source accusation adds no tier). Use it for one go/no-go read before accepting or sending funds. Not for freeze proposals, frozen balances or a freeze on another chain (frozen_elsewhere): get_address_compliance. Not for taint hops or the haircut: get_address_exposure. Not for open allowances: get_address_approvals. 'unknown' means the check did not finish, never 'checked clean'; evidence and incomplete_reasons name the cause (e.g. time_budget: the exposure walk was cut, a quieter moment may complete it). The freeze input is this chain's per-token status alone: frozen/seized argues for high, and an 'unknown' status or a pair whose freeze history is not backfilled turns a would-be 'none' into 'unknown' — so a Solana tier, where every freeze pair is unknown, is never 'none'. The exposure walk behind the tier is fixed at 3 hops; pick depth and window with get_wallet_graph_walk. A verdict is reused for up to 60 s (10 s after a time_budget cut). Heavy read: under load it answers busy or timeout — retry with backoff. No auth; 1200 requests/min shared by all tools. Not an identity, AML or legal determination.get_recent_transactionsRecent stablecoin transfers on one chain, newest first, filterable by payer and/or recipient, cursor-paginated. Use it for the latest transfers of an address or of the whole chain, with a tx_hash to cite. Not for who an address settles with over time: get_wallet_graph_walk. Not for how fresh the feed is: get_sync_status. Not for any verdict about an address: get_address_risk. Answer: items[], each row tx_hash, log_index, block_number, block_time (RFC 3339), payer, recipient, amount {amount (minor units, string), decimals, token (symbol)}, token (the contract address), finality, and usd_amount where priced. The chain is the one asked for — rows do not repeat it. payer and recipient narrow together; omit both for the chain-wide feed; pass next_cursor back unchanged as cursor for older rows, and a page without it is the last. Heavy read: under load it answers busy or timeout — retry with backoff. No auth; 1200 requests/min shared by all tools. Plain on-chain Transfer facts, no scoring.get_sanctions_statusOFAC SDN list coverage as this scanner holds it: evm_count, solana_count, tron_count and total addresses loaded (the free public 0xB10C list of US-Government public-domain data), updated_at of the last refresh (null until the first ingest) and the source. Use it to date the sanctions input behind a verdict, or to tell a clear OFAC flag from an unloaded list. Not for whether one address is listed: get_address_compliance (the flag) or get_address_risk (the tier). Not for indexer freshness: get_sync_status. No parameters; one answer covers every chain. Light read, never waits for a slot. No auth; 1200 requests/min shared by all tools. Verify against the official SDN list before acting on it; not legal advice.get_sync_statusIndexer freshness for one chain: freshness_seconds (the age of the newest indexed transfer; null when it could not be read for this answer), the indexer's head and finalized blocks, its safe block and its lag in blocks (lag_blocks = head_block - last_indexed_block). Use it before trusting how recent an address answer is, or to tell an empty feed from a stalled indexer. Not for how fresh the OFAC list is: get_sanctions_status. Every address verdict already carries freshness_seconds, so call this only for the block numbers or for a chain you have not asked about yet. On Solana (chain -1) safe_block is the finalized slot, and lag_blocks is near 0 by construction and never negative, so it is not a freshness signal there: read freshness_seconds. On the EVM chains and Tron a negative lag_blocks means the node's head went back. chain is the only parameter; omit it for Base. Light read, never waits for a slot. No auth; 1200 requests/min shared by all tools.get_wallet_graph_walkBounded walk over the indexed settlement graph of one stablecoin from one wallet on one chain: payer<->recipient hops with value-weighted scores, entity-aware node keys, a stop at known services and sanctioned-node markers. Use it to explain who an address settles with and through which hops. Not for a verdict: get_address_risk. Not for the taint class or haircut: get_address_exposure. Not for a flat list of transfers with tx hashes: get_recent_transactions. token is required and must be a stablecoin enabled on that chain (a refusal names them); hops=0 with stop_on_sanctioned=true is the cheapest check of the subject itself; subjects over the degree gate (~50k edge-rows) return hop 1 only with frontier_truncated=true. Heavy read: under load it answers busy or timeout — retry with backoff, a narrower window or a lower frontier_cap. No auth; 1200 requests/min shared by all tools. An explainability primitive, not a detector verdict, identity/control assertion, AML decision or legal advice. window_from present means the answer was built from that date, the edge-grain horizon, not from the start of the requested window; the default window all, 90d and 1y included (/v1/methodology edge_grain_horizon). When window_from is present, read the graph as covering that span only — do not treat the absence of a counterparty, a path or a sanctioned node as evidence about anything before that date. volume on nodes is the token's raw minor units (divide by 10^decimals); volume_usd6 is the same amount in USD with 6 decimals at peg 1. On Solana (chain -1) the answer carries coverage_status for the subject address only, never for its counterparties: pending — its history is still being filled, so an empty or small answer is not final; partial — filled to a documented bound. The walk shows a finished fill after the next Solana rollup pass (about 10 minutes), and never shows history older than window_from. This read never starts a fill, so pending can also mean none was asked for yet: one compliance read of the address asks for it. A Solana answer without coverage_status could not read it in time — treat it as pending. On Solana (chain -1) the edge grain of 2026-07-20..2026-09-14 is incomplete: those days hold part of their transfers or none, because their raw rows were offloaded before a fix reached production on 2026-09-17; they are not restored, and answers do not mark them (decision of 2026-09-17). Solana's grain is never trimmed, so there the horizon that window_from reports is not where retained data ends: once window_from is later than 2026-09-14 the answer holds none of those days. An answer that reaches them — window_from on or before 2026-09-14, or no window_from over a window that includes them — counts them as floors: at least this much, never the whole, and a counterparty, path or sanctioned node missing from those days is not evidence that there was none.
Tonnode MCP tools 16
get_masterchain_infoLatest TON masterchain block: workchain, shard, seqno and block hashes. Use when: checking that the network (or your endpoint) is alive and synced, or when you need the current block height. Returns: workchain, shard, seqno, rootHash/fileHash in base64. Tip: masterchain produces a block roughly every 3 seconds — if seqno does not grow between calls, the liteserver is lagging.get_balanceNative GRAM coin balance of a TON address (GRAM is the renamed Toncoin; the network is still called TON). Use when: the question is about the native coin only. For token balances (USDT and other jettons) use get_jetton_balance; for deployment status, code flags and the last transaction use get_account_state. Returns: balance_gram (decimal string, e.g. "12.5"), balance_nano (string, 1 GRAM = 1e9 nano) and at_seqno — the masterchain block the reading is anchored to. Never-funded (uninitialized) addresses return 0 — that is not an error.get_account_stateFull account state of a TON address: status (active / frozen / uninit), GRAM balance, last-transaction pointer (lt + hash) and whether contract code/data are deployed. Use when: checking if a contract or wallet is deployed, diagnosing why an address does not respond, or before run_get_method (which needs status=active). Returns: status, balance_gram, last_transaction {lt (string), hash — 64-char hex}, has_code, has_data, at_seqno. Reading the result: status=uninit with a non-zero balance means funds arrived but the wallet contract is not deployed yet; the last_transaction pointer is the cursor get_transactions starts from.get_transactionsRecent transactions of a TON address, newest first. Use when: verifying that a payment arrived, listing latest wallet activity, or tracing what an address did recently. Returns an array of {hash, lt (string), unix_time, in_value_gram, in_from, out_messages, total_fees_gram} — in_value_gram/in_from describe the incoming message (null for outgoing-only transactions). Never-active addresses return an empty array (not an error); an undecodable transaction comes back as {hash, parse_error: true}. No pagination: each call reads from the account's newest transaction — at most the 30 most recent are reachable. History depth: an error like "lt not in db" means this liteserver has already pruned that part of history — only archive endpoints keep the full chain; retry through one (TON_LITESERVERS or a TONNode hosted key) for deep history.run_get_methodExecute a read-only get-method (no gas, no state change) on a smart contract: seqno, get_jetton_data, get_sale_data, get_collection_data and anything else the contract exposes. Use when: reading typed on-chain data from a specific contract. The contract must be active — check with get_account_state first if unsure. Args: only integer arguments are supported here (decimal strings); methods that need an address/slice argument have dedicated tools — e.g. use get_jetton_balance instead of calling get_wallet_address manually. Returns: exit_code (0 or 1 = success; 11 usually means the contract has no such method; other values are contract-specific errors) and the result stack — typed items like {type:"int", value} or {type:"cell"|"slice", boc_base64}.get_jetton_balanceJetton (TON token) balance of an owner address — USDT and every other TEP-74 token. Use when: the question is about token balances rather than the native GRAM coin (for GRAM use get_balance). Args: owner — the holder's address; jetton_master — the token's master contract address. How it works: derives the owner's jetton-wallet address from the master, then reads its balance on-chain. Returns: jetton_wallet (the derived address), balance in raw indivisible units (string), deployed — false means the owner never held this token, so the balance is 0 — and at_seqno. Raw units: divide by 10^decimals; USDT uses 6 decimals, most other jettons 9 (read decimals from the master's metadata via run_get_method get_jetton_data).get_jetton_infoMetadata of a jetton master (token) contract: name, symbol, DECIMALS, total supply, mintable, admin. Use when: you need a token's decimals to convert raw indivisible units — swap quotes and balances are in raw units, so a human amount = raw / 10^decimals (USDT is 6, most jettons 9). Call this before get_swap_quote/build_swap_tx when you don't know the token's decimals. Args: jetton_master — the token's master contract address (e.g. USDT "EQCxE6mUtQJKFnGfaROTKOt1lZbDiiX1kCixRv7Nw2Id_sDs"). Returns: name, symbol, decimals (a number, or null when the token stores metadata off-chain), description, total_supply (raw), mintable, admin, metadata_type (onchain/offchain) and metadata_uri. Off-chain tokens keep name/symbol/decimals in a JSON file at metadata_uri — this tool returns the URI but does not fetch it, so decimals may be null (assume 6 for USDT-like, 9 otherwise, or fetch the URI).parse_addressParse, validate and convert a TON address between all its formats — purely local, no network access. Use when: normalizing user input, comparing addresses that look different but may be the same account, or converting to the raw form that indexers and APIs expect. Accepts friendly (EQ…/UQ…, with or without URL-safe characters) and raw (workchain:hex) forms. Returns: raw, friendly_bounceable (EQ…), friendly_non_bounceable (UQ…), workchain and flags of the given input. Background: EQ… and UQ… encode the SAME account — EQ (bounceable) is conventional for contracts, UQ (non-bounceable) for user wallets; two addresses are equal if their raw forms match.get_swap_quoteFirm swap quote for exchanging GRAM or any jetton into another asset on TON, via the Omniston protocol (STON.fi RFQ aggregation over STON.fi/DeDust liquidity). MAINNET only. Use when: an agent wants to know the current exchange terms, or as step 1 of an actual swap (step 2 is build_swap_tx with the returned quote_id). For swaps INTO another blockchain (ETH, Base, BNB…) use get_crosschain_quote instead. Amounts are raw indivisible units — GRAM has 9 decimals (1 GRAM = 1e9), USDT has 6; read a jetton's decimals via run_get_method get_jetton_data if unsure. Returns: quote_id (pass it to build_swap_tx PROMPTLY — quotes expire in about a minute), input/output amounts, min_output_units (the on-chain slippage floor the swap will be built with — the only guaranteed minimum), price_impact_bps, integrator_fee_units (revenue share of the server operator, if configured — already deducted from output_units), gas_budget_nano (GRAM the wallet must additionally hold for gas) and the DEX route. This is a price lookup only — nothing is signed or sent.build_swap_txBuild the UNSIGNED transaction for a swap quoted by get_swap_quote. Non-custodial: this returns TonConnect-ready messages — nothing is signed and nothing is sent; the wallet owner signs and broadcasts them (e.g. tonConnectUi.sendTransaction(result.tonconnect)). The messages MOVE REAL FUNDS once signed, so treat the output as an armed payment and show it to the wallet owner before sending. Use when: an agent (or the app driving it) actually wants to execute the swap after inspecting the quote. Args: quote_id from get_swap_quote (use it promptly — expired quotes fail and need a re-quote) and wallet — the address that will send the transaction, receive the swap output and any gas excess. Returns: tonconnect {validUntil, network, messages[{address, amount, payload, stateInit?}]} with base64 BoC payloads, exactly the shape TonConnect sendTransaction expects. Omniston emulates the transfer while building — if the wallet lacks the input funds, this fails up front. The wallet must hold the input amount (for GRAM swaps it is included in the attached value) plus the quote's gas_budget_nano in GRAM.get_crosschain_quoteFirm quote for swapping GRAM or a TON jetton into an asset on another blockchain (Ethereum, Arbitrum, Base, BNB, Polygon, Avalanche) via Omniston's atomic HTLC escrow settlement. MAINNET only. TON is always the source chain — the trade is initiated and funded by a TON wallet. Use when: an agent needs USDT/USDC/native coins delivered to an EVM address, paid from TON. Step 2 is build_crosschain_swap_tx with the returned quote_id. Amounts are raw indivisible units of each asset (TON USDT = 6 decimals, GRAM = 9, EVM tokens per their own decimals). Returns: quote_id (use PROMPTLY — quotes expire in about a minute), input/output amounts, fees, gas_budget_nano (GRAM needed for gas on TON), security_deposit (extra value temporarily locked in the escrow, returned on completion), htlc_hashing_function (COPY IT VERBATIM into build_crosschain_swap_tx) and estimated_settlement_seconds for the full cross-chain trade. This is a price lookup only — nothing is signed or sent.build_crosschain_swap_txBuild the UNSIGNED TON escrow transaction for a cross-chain swap quoted by get_crosschain_quote, and generate the HTLC secret that later completes it. Non-custodial: nothing is signed or sent, and the server does NOT keep the secret — it exists only in this response. The messages MOVE REAL FUNDS once signed; treat the output as an armed payment. Treat htlc_secret like a payment authorization: anyone who sees it together with quote_id can trigger disclosure — keep this response out of logs and shared contexts. EVERY CALL GENERATES A NEW SECRET bound to THIS tonconnect payload — if you rebuild for the same quote, discard every earlier payload and secret; signing an older payload after a rebuild locks funds under a hash whose secret you no longer track. THE FLOW AFTER THIS CALL: (1) the wallet owner signs and sends result.tonconnect; (2) poll track_crosschain_swap every ~10s; (3) when an execution's dst_phase reaches ready_for_private_completion, call disclose_crosschain_secret PROMPTLY with htlc_secret (the tool re-verifies the on-chain state before revealing anything); (4) if nothing fills and cancellation_mode becomes onchain, reclaim funds with build_crosschain_refund. STORE htlc_secret UNTIL THE TRADE COMPLETES — without it the trade cannot settle (funds remain refundable after the timeout, but the swap is lost).- +4 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Stablecoin Scanner (StableScan)
{
"mcpServers": {
"stablecoin-scanner-stablescan": {
"url": "https://stablescan.achivx.com/mcp"
}
}
}
Tonnode MCP
{
"mcpServers": {
"tonnode-mcp": {
"command": "npx",
"args": [
"-y",
"@tonnode/mcp"
]
}
}
}
Frequently asked questions
Stablecoin Scanner (StableScan) is categorized under Finance & Fintech and uses a remote HTTP/SSE transport. Tonnode MCP belongs to Finance & Fintech and uses a local stdio subprocess. Pick Stablecoin Scanner (StableScan) for finance & fintech work and Tonnode MCP for finance & fintech.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Stablecoin Scanner (StableScan) is listed as free. Auth: no auth required. Tonnode MCP is listed as free. Auth: no auth required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add stablecoin-scanner-stablescan and tonnode-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Stablecoin Scanner (StableScan) has a quality signal of 56/100 (Good) with 0 views, 0 installs and 0 GitHub stars. Tonnode MCP has 67/100 (Great) with 4 views, 0 installs and 27 GitHub stars.