Scienter vs Tonnode MCP
A side-by-side look at the Scienter and Tonnode MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
S
ScienterFinance & Fintech · Remote HTTP/SSECrypto forensics with sources: deployer records, OFAC matches, exchange and bridge attribution.51GoodAuth: not declaredVerdict: choose Scienter 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?
SChoose Scienter when
- You need dedicated capabilities in the Finance & Fintech domain.
- You prefer a remote HTTP/SSE transport.
- You want tools like
solana_token, solana_deployer, wallet_score.
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 | S Scienter | |
|---|---|---|
| Category | Finance & Fintech | Finance & Fintech |
| Quality signal | 51/100 · Good | 67/100 · Great |
| Install command | Confirmed | Confirmed |
| Transport | Remote HTTP/SSE | Local subprocess (stdio) |
| Auth | Not declared | No auth required |
| Pricing | Not declared | 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 Scienter | View Tonnode MCP |
Tools & capabilities
Scienter tools 8
solana_tokenWho created a Solana token, and what that wallet's OTHER launches did. Takes a mint — the identifier a user actually has — and resolves the wallet that created it, which requires a census that watched Solana launches prospectively since 2026-09-08. EVERY NUMBER IT RETURNS COUNTS LAUNCHES BY THAT WALLET, NOT EVENTS IN THIS TOKEN. Never write that the token had launches or has a death rate; the true statement is about its maker, and it is a reason to look harder at the token rather than a measurement of it. Three outcomes, and they must not be collapsed: - flagged: every settled launch by the creating wallet has died. - not flagged: that wallet has a settled record and at least one launch survived. This is NOT a positive finding; it means the screen does not fire. - no record: either the mint is not one the census publishes evidence for, or its wallet has no settled launch on record. This is the answer for most of the chain and it is NOT a clean result — it is a statement about coverage. Never report it as clear. What the flag is worth, scored once on a later window: flagged launches were still listed a day later about 0.8% of the time against about 4.3% for the rest, non-overlapping 95% intervals. It is a NEGATIVE screen. It does not identify anything worth buying, and over this same data every return bucket loses money after costs. Never restate it as a recommendation, a risk score, or a safety verdict. Case is significant: a mis-cased mint is a different mint and will answer no record. Call this when a user asks about a specific Solana token, who made it, or whether its creator has a history. Use solana_deployer instead when a deployer wallet is already known. Args: - mint (string): a base58 Solana mint address, exact case.solana_deployerWhat the wallet that deployed a Solana token has done before: how many of its launches settled, how many died, and whether every one of them did. Built from a census that has watched Solana launches prospectively since 2026-09-08, which is why it can answer a question about the deployer rather than about the token. Three outcomes, and they must not be collapsed: - flagged: every settled launch by this wallet has died. - not flagged: a settled record exists and at least one launch survived. This is NOT a positive finding; it means the screen does not fire. - no record: no settled launch by this wallet was ever recorded. This is the answer for most of the chain and it is NOT a clean record — it is a statement about coverage, never about conduct. Never report it as clear. What the flag is worth, scored once on a later window: flagged launches were still listed a day later about 0.8% of the time against about 4.3% for the rest, non-overlapping 95% intervals. It is a NEGATIVE screen. It does not identify anything worth buying, and over this same data every return bucket loses money after costs. Never restate it as a recommendation, a risk score, or a safety verdict. Case is significant: Solana addresses are base58, and a mis-cased address is a different address that will answer no record. Call this when a user asks who made a Solana token, whether a deployer has a history, or whether a launch's creator has ever had one survive. Args: - address (string): a base58 Solana wallet address, exact case.wallet_scoreScienter's forensic read on one blockchain address: public block-explorer facts (age, activity, balance, bounded-window flows), the published exchange-wallet label when the address is one, the clustering engine's entity when it answers, and itemised findings with citations. This does NOT return a risk score. Scienter publishes no calibrated wallet-risk model and this tool will never emit a number to grade an address by. It returns evidence, and it reports explicitly when a check did not run -- an empty findings list with findings_checked=false means the engine did not answer and must not be read as a clean result. Args: - address (string): an EVM 0x address or a base58 Solana address.ofac_checkScreen one blockchain address against the U.S. Treasury OFAC SDN (Specially Designated Nationals) list: a direct match on the address itself, plus the engine's two-hop proximity walk over the address's real transfer history. Two separate claims, reported separately. Three direct-match outcomes, and they must not be collapsed: - a match: the address is published on the SDN list. The designated entity, its type, its sanctions programs and the chain OFAC filed it under are returned. - no match: the whole published list was searched and the address is not on it. That is a real finding about one list on one date. - not screened: the list could not be read, so nothing was checked. Never report this as clear; point the user at https://sanctionssearch.ofac.treas.gov/ instead. Proximity: when proximity_checked is true the engine walked up to two hops of transfer history (its warehouse or a live read) looking for a listed address, and reports found or not, the hop count, the path and how far it went. Being N hops from a listed address is a fact about the graph, never a designation. When proximity_checked is false nothing was walked and the result says so. Limits to repeat whenever the result is restated: SDN list only (not the EU, UN or UK/OFSI lists, and not OFAC's non-SDN lists such as SSI, NS-MBS and CAPTA); as published on a stated date; a walk bounded by hops and a node budget. A miss is not a sanctions clearance. Call this when a user asks about sanctions exposure, designation, or OFAC status for an address, so the answer is grounded in what was actually searched. Args: - address (string): an EVM 0x address or a base58 Solana address.cex_attributionLook up whether an address is a labelled centralised-exchange wallet in Scienter's published exchange-wallet table, whether any address clustered with it is, and what the address's own exchange activity looks like: its deposits to labelled exchange wallets and any per-user deposit addresses inferred from its behaviour, read from real transfer history (activity.checked says whether that read ran). The table is small (tens of addresses, from public block-explorer labels, activity-checked on chain) and a miss means no label is held -- not that the address is unaffiliated with an exchange. Critical limit on what a hit means: an exchange hot or cold wallet is paid by millions of unrelated people. Two addresses that both funded the same exchange wallet are two customers of that exchange and nothing more. Each row carries a clusterable flag saying whether it can be used to link addresses at all; this must be repeated whenever the result is restated. Args: - address (string): an EVM 0x address or a base58 Solana address.bridge_traceTrace an address's cross-chain bridge transfers: which transfers touched which bridge contracts, toward which chains, for how much, with the transaction hash of each. Scienter matches the address's transfer history (its own warehouse first, a live provider inside a budget after that) against a registry of bridge contracts across seven protocols. The registry is partial by construction, so an empty result means none of the tracked contracts were touched -- never that the funds did not bridge. The coverage and the caveat come back in the same payload and must be repeated whenever the result is restated. Three outcomes: transfers found (listed with amounts and hashes); none of the registry's contracts touched (a bounded negative); not traced (the engine did not answer, and nothing may be inferred). `truncated: true` means the provider's row cap was hit and every count is a lower bound. EVM addresses only; a Solana address is out of scope, which is a different fact from clear. Args: - address (string): an EVM 0x address (a base58 Solana address answers out of scope).leaderboard_queryList the addresses Scienter's risk model has flagged most recently, highest score first, with each row's chain, score, model version, top evidence and timestamps. Every row is a model output about a token contract's on-chain behaviour -- not a legal finding, not an audit, and not an allegation against any person. Widely held tokens are excluded by an allowlist and the suppressed count is reported, so this is a filtered view of the model's output. An empty list is reported as one of three things and they must not be conflated: a quiet day (the scorer ran and nothing crossed the threshold; a finding), a flag table no scorer has ever written (a gap in coverage; ever_written is false), or an unconfirmed read. A producer that did not answer at all is a fourth, reported as not_deployed. Args: - limit (integer, optional): maximum rows to return, 1-100 (default 20).receipts_lookupSearch Scienter's published forensic receipts -- written reconstructions of specific on-chain incidents -- by address or free text, and get back titles, dates, subjects and public URLs a human can open. There are only tens of receipts in total, each written for one investigation, so most addresses have none. No match is the normal case and is NOT evidence that nothing happened to or around the address. Unverified drafts are withheld from results and counted separately. Args: - address (string, optional): match receipts whose subject or deployer contains this. - q (string, optional): free-text match over title, description and tags. - limit (integer, optional): maximum receipts to return, 1-50 (default 20). Passing neither address nor q lists the most recent published receipts.
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.
Scienter
{
"mcpServers": {
"scienter": {
"url": "https://scienter.xyz/mcp"
}
}
}
Tonnode MCP
{
"mcpServers": {
"tonnode-mcp": {
"command": "npx",
"args": [
"-y",
"@tonnode/mcp"
]
}
}
}
Frequently asked questions
Scienter 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 Scienter 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.
Scienter has no declared pricing — check the project's own site. 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 scienter and tonnode-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Scienter has a quality signal of 51/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.