Scienter vs MCP Klever Vm
A side-by-side look at the Scienter and MCP Klever Vm 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 MCP Klever Vm 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 MCP Klever Vm 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
query_context, get_context, find_similar.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | S Scienter | |
|---|---|---|
| Category | Finance & Fintech | Finance & Fintech |
| Quality signal | 51/100 · Good | 63/100 · Good |
| 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 | — | 31 |
| Directory activity | 0 views 0 installs 0 upvotes | 4 views 0 installs 0 upvotes |
| Tools | 8 | 23 |
| Full listing | View Scienter | View MCP Klever Vm |
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.
MCP Klever Vm tools 23
query_contextSearch the Klever VM knowledge base for smart contract development context. Returns structured JSON with matching entries, scores, and pagination. Use this for precise filtering by type or tags; use search_documentation for human-readable "how do I..." answers.get_contextRetrieve a single knowledge base entry by its unique ID. Returns the full entry including content, metadata, tags, and related context IDs. Use this after query_context or find_similar to get complete details for a specific entry.find_similarFind knowledge base entries similar to a given entry by comparing tags and content. Returns related contexts ranked by similarity score. Useful for discovering related patterns, examples, or documentation after finding one relevant entry.get_knowledge_statsGet summary statistics of the Klever VM knowledge base. Returns total entry count, counts broken down by context type (code_example, best_practice, security_tip, etc.), and a sample entry title for each type. Useful for understanding what knowledge is available before querying.enhance_with_contextAugment a natural-language query with relevant Klever VM knowledge base context. Extracts Klever-specific keywords, finds matching entries, and returns the original query combined with relevant code examples and documentation in markdown. Use this to enrich a user prompt before answering Klever development questions.search_documentationSearch Klever VM documentation and knowledge base. Returns human-readable markdown with titles, descriptions, and code snippets. Optimized for "how do I..." questions. Use this instead of query_context when you need formatted developer documentation.analyze_contractAnalyze Klever smart contract Rust source code for common issues. Checks for missing imports, missing #[klever_sc::contract] macro, missing endpoint annotations, payable handlers without call_value usage, storage mappers without #[storage_mapper], and missing event definitions. Returns findings with severity (error/warning/info) and links to relevant knowledge base entries.get_balanceGet the KLV or KDA token balance for a Klever blockchain address. Returns the balance in the smallest unit (for KLV: 1 KLV = 1,000,000 units with 6 decimal places). Optionally specify an asset ID to query a specific KDA token balance instead of KLV.get_accountGet full account details for a Klever blockchain address including nonce, balance, frozen balance, allowance, and permissions. Use this when you need comprehensive account state beyond just the balance.get_asset_infoGet complete properties and configuration for any asset on the Klever blockchain (KLV, KFI, KDA tokens, NFT collections). Returns supply info, permissions (CanMint, CanBurn, etc.), roles, precision, and metadata. Note: string fields like ID, Name, Ticker are base64-encoded in the raw response.query_scExecute a read-only query against a Klever smart contract (VM view call). Returns the contract function result as base64-encoded return data. Arguments must be base64-encoded. Use this to read contract state without modifying it.get_transactionGet transaction details by hash from the Klever blockchain. Returns sender, receiver, status, block info, contracts, and receipts. Uses the API proxy for indexed data.- +11 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"
}
}
}
MCP Klever Vm
{
"mcpServers": {
"klever-io-mcp-klever-vm": {
"command": "npx",
"args": [
"-y",
"@klever/mcp-server"
]
}
}
}
Frequently asked questions
Scienter is categorized under Finance & Fintech and uses a remote HTTP/SSE transport. MCP Klever Vm belongs to Finance & Fintech and uses a local stdio subprocess. Pick Scienter for finance & fintech work and MCP Klever Vm 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. MCP Klever Vm 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 klever-io-mcp-klever-vm 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. MCP Klever Vm has 63/100 (Good) with 4 views, 0 installs and 31 GitHub stars.