Provides tools for inspecting Solana token risk, including mint/freeze authorities, Token-2022 controls, holder-account concentration, early acquisition coordination, Jito tips, and mother-wallet funding clusters.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cabal-radar-mcp check this Base token for risks: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Solana & Base token risk intelligence for MCP assistants and the terminal. Zero external runtime dependencies. Open-source Node.js ESM. Built by c-viper-work.
Inspect Solana mint/freeze authorities, Token-2022 controls, holder-account concentration, early acquisition coordination, Jito tips and mother-wallet funding clusters. Inspect Base ERC20 metadata, dangerous bytecode patterns, earliest observed Transfer concentration and transfer restrictions. Activate local Pro with an on-chain payment receipt; no central license server, private keys or wallet connection.
Landing page · Source · Trust model
This is heuristic investigation software, not a completed security audit. A high safety score does not establish safety. Tax and honeypot results remain UNKNOWN when the available evidence cannot establish them. Launch coverage is never implied by a bounded historical sample.
Requires Node.js 22+. No dependency install is needed to run a source checkout:
git clone https://github.com/c-viper-work/cabal-radar-mcp.git
cd cabal-radar-mcp
node bin/cabal-radar.js --help
npm test
npm install -g .Or install from the public GitHub repository when available:
npm install -g github:c-viper-work/cabal-radar-mcpAfter the maintainer publishes version 1.0.0 to npm, npm install -g cabal-radar-mcp@1.0.0 and npx -y cabal-radar-mcp@1.0.0 mcp are equivalent distribution options. This source tree does not imply that npm publication, registry listing or a hosted deployment has occurred.
Both cabal-radar and cabal-radar-mcp are executable aliases. No arguments starts MCP stdio. npm start also starts MCP; clients should use the binary directly to avoid npm's stdout banners.
Related MCP server: Sol MCP — Solana Token Risk & Signals
cabal-radar scan EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v --chain solana --json
cabal-radar scan 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 --chain base --json
cabal-radar upgrade
cabal-radar activate --tx <transaction_hash_or_signature> --chain <base|solana>
cabal-radar status
cabal-radar scan <token_address> --chain solana --pro --json
cabal-radar mcpReplace angle-bracket placeholders before running. Solana is the default chain. --pro returns both basic and deep results after activation; without a valid license it prints upgrade information and exits with status 1. Input/RPC failures also exit 1; successful commands exit 0. CLI activation only reads chain state and writes a local license. No command submits transactions or approves tokens.
Install the binary globally first, ensure the client can find it on PATH, then merge this entry into the client's MCP server configuration:
{
"mcpServers": {
"cabal-radar": {
"command": "cabal-radar-mcp",
"args": ["mcp"],
"env": {
"SOLANA_RPC_URL": "https://api.mainnet-beta.solana.com",
"BASE_RPC_URL": "https://mainnet.base.org"
}
}
}
}In Claude Desktop, open its developer/MCP configuration. In Cursor or Windsurf, use MCP server settings and add a stdio command, or merge the object above into the JSON editor if provided. Exact settings labels vary by client version. Restart/reconnect the server and confirm six tools appear. Keep RPC credentials in client environment configuration; do not commit them.
The CLI works as a local process tool: invoke cabal-radar scan <address> --chain <chain> --json. If your OpenClaw installation has an MCP bridge, register cabal-radar-mcp with argument mcp through that bridge. The mcpServers object above is not asserted to be a native OpenClaw configuration schema. Configure any process-tool approval rules in your agent host; this package never requires wallet-signing permissions.
Tool | Tier | Inputs / behavior |
| Free |
|
| Free | No arguments; exact payment routes, machine label and activation instructions |
| Free |
|
| Pro |
|
| Pro |
|
| Pro |
|
The deep Base tool also accepts fromBlock (nonnegative integer, within 10,000 blocks of the head), simulationFrom, simulationTo and simulationAmount (raw-unit decimal string). All three simulation fields are required together. The sender needs a real token balance for a meaningful eth_call; no transaction is broadcast. Markdown reports are returned alongside structured results, not written to arbitrary filesystem paths.
Example MCP tools/call arguments:
{
"name": "batch_audit_watchlist",
"arguments": {
"tokens": [
{"chain": "base", "address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"},
{"chain": "solana", "address": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"}
],
"format": "markdown"
}
}Transport is newline-delimited JSON-RPC 2.0 on stdio. Supported methods: initialize, notifications/initialized, notifications/cancelled, ping, tools/list, tools/call. Protocol versions: 2025-11-25, 2025-06-18, 2025-03-26, 2024-11-05; an unknown requested version receives the newest supported version. Stdout contains only protocol responses. Notifications have no responses. Tool calls run at most four at a time with up to 64 pending calls; excess calls return JSON-RPC error -32000 Server busy. Initialization requires a nonempty string clientInfo.version. Ping, initialization, tool listing and notifications bypass the tool queue; clients must match responses by ID. Cancellation removes queued calls immediately, aborts in-flight fetch RPCs and suppresses the cancelled tool response. Input is limited to 1 MiB per line; MCP batches and legacy Content-Length framing are not supported.
Run cabal-radar upgrade to obtain the deterministic CR-<12 hex characters> local machine label. Send one qualifying payment using the correct network and asset:
Network | Recipient | Asset | Minimum raw amount |
Base mainnet (8453) |
| Native ETH |
|
Base mainnet (8453) |
| USDC |
|
Solana mainnet-beta |
| Native SOL |
|
Solana mainnet-beta |
| SPL USDC |
|
Official USDC identities (six decimals):
Base contract: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
Solana mint: EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v
Keep native currency for network fees. Do not send a different token, use a testnet, or send Base USDC to the token contract as the recipient. Then:
cabal-radar activate --tx <base_transaction_hash> --chain base
# OR
cabal-radar activate --tx <solana_signature> --chain solana
cabal-radar statusBase verification checks eth_chainId, transaction/receipt consistency, successful mined status, and either a direct native payment or a matching official USDC Transfer event. Native internal transfers are not accepted. The USDC threshold applies to a single Transfer event. Solana verification checks the mainnet genesis hash, successful confirmed parsed transaction, signature and slot, then the recipient's net SOL increase or net USDC increase across its token accounts. Transfers between the recipient's own accounts do not create a qualifying USDC net increase. Precision-unsafe numeric balances fail closed.
Default storage is ~/.cabal-radar/license.json, privately created and atomically replaced. The saved record contains only version, hashed machine ID, transaction identifier, chain and HMAC. Machine input strings are not saved or sent to a server. Activation does not require putting the challenge in a memo. Reinstalling or moving machines can change the local ID; reactivate on the destination machine.
Setting | Default | Purpose |
|
| Solana mainnet RPC |
|
| Base mainnet RPC |
|
| Local license override |
Basic scans verify Base mainnet chain ID or Solana mainnet genesis before reading token data. Solana funding tracing verifies mainnet genesis once before reading holder histories. RPC requests have a 15-second timeout and support options.signal cancellation for fetch transports. Errors do not print endpoint URLs or provider messages that might contain credentials. Public providers may rate-limit or lack archive history. The library supports rpcUrl, timeoutMs, fetch or an injected async rpc(method, params) for custom transport/testing. Explicit programmatic options take precedence over defaults. Do not inject untrusted RPC implementations: all chain evidence is only as trustworthy as the provider.
import {
scanSolanaTokenBasic,
detectBaseEarlyBundlerAndHoneypot,
getMachineChallenge,
saveLicense
} from 'cabal-radar-mcp';
const report = await scanSolanaTokenBasic(
'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v'
);
console.log(report.safetyScore, report.flags);Deep scans return their basic result and accept options.basic for trusted internal reuse of a completed basic scan for the same token, chain and provider. CLI, Worker and batch paths perform each basic scan once. No public tool argument can bypass network verification.
Solana deep scans also sample up to five top holder token-account histories (one page and ten transactions each), deduplicating signatures across all sampled accounts before fetching transactions. coverage.holderAccountsSampled reports this additional coverage; transaction counts are unique across histories. Solana acquisition clusters connect events whose consecutive slots differ by at most two; connected clusters may span more than two slots. Unresolved holder accounts are reported in coverage.unresolvedHolderAccounts and coverage.unresolvedSupplyPct; clustered exposure is null when all holder accounts are unresolved.
Low-level scanner exports are intentionally callable directly in an open-source library. The Pro tier is enforced at the MCP/CLI interface, not as an anti-circumvention security boundary. saveLicense({chain, txHash}, options) independently verifies payment before writing; a caller-supplied verified flag cannot bypass verification. checkProStatus(options) returns {active,tier,machine_id,challenge,...}. Status is offline and does not re-query the chain.
Solana basic: validates decoded 32-byte base58 keys and parsed mint ownership; checks mint/freeze control, permanent delegates, transfer hooks, ≥10% transfer-fee configuration, default frozen accounts and top-ten token-account share. Pools, burn addresses and vaults are not labeled or removed.
Solana coordination: paginates up to three pages of 100 signatures, then loads up to 40 of the oldest successful transactions in that sample. Positive owner token deltas are acquisition candidates. Disjoint windows of at most two slots flag multiple wallets; actual parsed system transfers to the documented Jito tip accounts are noted. These are not proven DEX buys or atomic bundles. bundledSupplyPct is current top-account exposure to flagged owners, not original bought supply.
Solana funding: up to 20 provided wallet owners; default one page and ten oldest sampled transactions per owner. Orders same-slot signatures by reverse RPC response index and interleaves each top-level instruction with its CPI instructions in execution order. Groups the first observed inbound SOL transfer of at least 1,000,000 lamports (0.001 SOL) by source; library callers can set options.minFundingLamports. coverage.ignoredDustTransfers counts ignored smaller transfers, and per-wallet coverage is in coverage.holders. Different-source events form connected timing groups when consecutive times differ by at most 60 seconds; a connected group may span longer than 60 seconds. sybilClusterPct is the fraction of provided unique wallets sharing a source, not supply percentage; timing-only groups are excluded.
Base basic: reads code and ERC20 metadata, disassembles PUSH instructions to avoid interpreting PUSH data as opcodes, and identifies selected control selectors. All bytecode is scanned, including metadata, to prevent forged metadata from hiding executable jump targets. This conservative choice can flag bytes in genuine metadata. Dynamic code paths, computed selectors, proxy implementation logic and role access are not fully analyzed.
Base deep: defaults to the last 2,000 blocks, queried in 500-block chunks. Anchors on the earliest positive-amount non-mint/non-burn Transfer block and its successor (coverage.firstTransferBlock), reports the earliest observed block including mints as coverage.firstObservedBlock, excludes zero amounts, and aggregates gross recipient transfer volume. Gross volume is not token supply and can include repeated transfers. Optional eth_call checks an explicitly provided transfer scenario; reverts, false returns and nonstandard returns are review signals, not proof of honeypot. Generic RPC/node failures propagate instead of being treated as reverts. Exact buy/sell tax needs funded, route-specific fork simulation and remains unknown here. Standard approve/permit capability is informational, not evidence of malicious approval behavior.
Scores start at 100 and subtract explicit per-flag penalties, clamped at zero. Risk bands: LOW 81–100, MEDIUM 51–80, HIGH 26–50, CRITICAL 0–25. A zero-flag report still carries evidence limitations. Unknown data is not a safety guarantee.
Zero central server does not mean zero network access. Token addresses and transaction identifiers are sent to configured RPC providers, which see request metadata. There is no telemetry, hosted activation database, private-key input, wallet connection, trading or automatic signing.
Public receipts are replayable. A transaction hash alone cannot prove that the caller paid, bind a payment to a machine challenge, or enforce globally unique use. The deterministic HMAC provides machine-bound local consistency, not a secret that a local attacker cannot reproduce. This release does not claim payer authentication, tamper-proof licensing or one-payment-per-machine enforcement. Solving those requires a different authorization scheme, such as a signed payer challenge plus an on-chain entitlement or shared redemption state.
Confirmation is not finality. Base accepts a mined successful receipt; Solana uses confirmed. Reorganizations remain possible. Saved licenses are not continuously revalidated. Neither the machine challenge nor tokens are transmitted to an activation backend.
Coverage is bounded. RPC history can be pruned, omit mint-related transfers that do not reference the mint account, or omit original wallet funding. The oldest available transaction is not proof of launch. Common exchange funding can resemble a sybil cluster. No historical absence result establishes absence of coordination.
cloud-worker/worker.js uses only portable Web APIs and the shared scanner/payment modules. Local operation does not depend on it. Cloudflare's module-worker entry exports {fetch}; the deployment bundle must include the relative src/ imports. A deployment configuration is included in cloud-worker/wrangler.toml. Use an installed deployment CLI from the project root:
wrangler deploy --config cloud-worker/wrangler.tomlFor Deno, the included entry module is cloud-worker/deno.js. Free-tier feasibility depends on current provider CPU/subrequest limits and RPC throughput; no hosting or always-free SLA is promised. Deep scans may exceed low-tier quotas. Deployments, provider accounts and publication are not performed by this package.
Endpoints:
GET /health: package/version metadata.
POST /scan: body { "address": "...", "chain": "base" }. Without payment headers, returns HTTP 402 and exact payment instructions. Retry with X-Payment-Tx and X-Payment-Chain; a qualifying receipt unlocks basic + deep scanning for that request.
This is the onchain-receipt-v1 HTTP 402 scheme, not the x402 exact payment-signature/facilitator settlement protocol. It does not advertise standards-compliant x402 support. Receipts act as reusable public bearer proofs, so this endpoint is unsuitable for authenticated billing or per-request paywalls. The operator should understand this before public deployment. Client-supplied RPC endpoints are rejected. Configure RPC URLs in deployment environment variables. The worker has no persistent license storage, CORS relaxation or automatic payment settlement.
glama.json supplies the maintainer claim for Glama. smithery.yaml supplies the stdio launch command/configuration. Registry acceptance, organization ownership and current hosting capabilities must be verified by the maintainer; metadata does not automatically publish or guarantee one-click installation. Local license persistence is host-specific in containers.
For MCP directories such as mcp.so, Smithery, Glama and Awesome-MCP, use:
cabal-radar-mcp — zero-dependency Solana and Base MCP server and CLI for token risk heuristics, Token-2022 controls, early bundler signals, shared-funder clusters and on-chain Pro activation.
Category: blockchain / security / developer tools. License: MIT. Transport: stdio. Repository owner: c-viper-work.
The static, self-contained docs/index.html is ready for a GitHub Pages source of branch /docs after the repository is published. It has accessible setup tabs, clipboard buttons, mobile layout, exact payment routes and no third-party scripts or external fonts. Clipboard access requires HTTPS or a secure local origin; otherwise the text is selected for manual copy. It never requests wallet access or initiates payment.
npm test
node bin/cabal-radar.js --help
npm pack --dry-runTemporary test files fall back to a workspace directory if the OS temporary directory is read-only or permission-restricted. Audit regression cases are in test/audit.test.js; CLI, Worker and batch integration tests also reject or count duplicate basic scans.
Test helpers try the system temp directory, then the workspace. If both deny writes, a test-only virtual filesystem preserves license integrity and CLI subprocess coverage without changing production storage. Run NODE_OPTIONS='--import=./test/readonly-preload.js' npm test to inject read-only write failures across the suite; virtual file modes do not verify operating-system permission enforcement.
Tests use Node's built-in test runner and synthetic chain fixtures. They cover minimums, wrong networks/assets/recipients, failed transactions, integer precision, license tampering, Solana/Base analysis, opcode disassembly, protocol framing, gating, CLI subprocesses and edge 402 responses. Spawned CLI tests use a preload fixture at the fetch boundary so they do not require listening sockets or paid RPC access. They do not establish live mainnet availability, actual transfer execution, public deployment or registry acceptance. No real payments, private data or testnet transactions are required.
Architecture: constants → rpc / payments → scanners → service → CLI/MCP. license is Node-only; the Worker imports the portable payment module directly. No runtime dependency lockfile is needed.
MIT © 2026 c-viper-work. See LICENSE.
Verify a mainnet payment receipt and save a machine-bound local Pro license.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | solana | |
| txHash | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it partially discharges it: it reveals that verification targets a mainnet receipt and that the resulting license is local and machine-bound. It says nothing about idempotency, behavior when a license already exists, failure modes, or the file location the license is written to.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that names both the verification step and the persistence step with no filler, hedging, or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys the core contract, but with no annotations, no output schema, and zero parameter documentation, an agent still lacks error/return expectations and the meaning of the two required inputs. It is minimally adequate for a payment-gated mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain both parameters, but it never names txHash or chain and does not mention that chain accepts only solana/base with a solana default. 'Mainnet payment receipt' only loosely implies a transaction hash and chain context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific compound verb+resource: it verifies a mainnet payment receipt and writes a machine-bound local Pro license. That is far more specific than a tautology, but it never references the sibling get_pro_upgrade_info or otherwise positions itself relative to the other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use statement, no prerequisites, and no routing to alternatives such as get_pro_upgrade_info for users who have not yet paid. Usage must be inferred entirely from the name and the phrase 'mainnet payment receipt'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pro: audit up to 20 tokens with bounded concurrency; return JSON and optional Markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | json | |
| tokens | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses bounded concurrency, the 20-token cap, output format choice, and a Pro-tier hint, but it omits whether the operation is read-only, any auth/license details beyond the prefix, and failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no wasted words. It packs the core purpose, cap, concurrency behavior, and output options efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There are no annotations and no output schema, so the description should do more to explain what an 'audit' returns, what chains are supported, and how the token objects are structured. As written, an agent lacks enough context to call this correctly beyond the basic batch shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions the format enum and the 20-token maximum, but it says nothing about the per-token address field, the chain enum, or the default chain, leaving key parameter semantics unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'audit up to 20 tokens', and the batch nature is clear from the tool name and the cap. It does not explicitly distinguish this from the sibling scan_token_safety, so a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Pro:' prefix hints at a license requirement, and the 20-token cap implies batch use, but there is no explicit when-to-use guidance, no exclusions, and no mention of when to use scan_token_safety instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pro: bounded early-acquisition analysis. Launch coverage is explicitly reported.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | solana | |
| address | Yes | ||
| fromBlock | No | ||
| simulationTo | No | ||
| simulationFrom | No | ||
| simulationAmount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses almost nothing behavioral: "bounded" is unexplained (bounded how — block range, depth, compute?), and "Launch coverage is explicitly reported" hints at output content but not its form. Auth/tier requirement is only implied by the "Pro:" prefix.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments are not concise but under-specified — brevity here comes at the cost of the information the agent needs. Structure is front-loaded with the least informative token ("Pro:").
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with no annotations, no output schema, and 0% schema coverage, the description supplies essentially none of the missing context. Nothing about chain behavior, simulation parameter interactions, or result shape is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 6 parameters, and the description mentions none of them. Cryptic names like simulationFrom/simulationTo/simulationAmount and the fromBlock bound are left entirely unexplained, so an agent must guess at required formats and interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Bounded early-acquisition analysis" gestures at the domain (early/launch-phase activity) but never states the actual verb+resource: detecting block-0 bundlers. An agent cannot tell what it produces or how it differs from siblings like scan_token_safety or trace_funding_clusters. The name carries more meaning than the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage signal is the "Pro:" prefix, which implies a license/tier prerequisite. There is no when-to-use, when-not-to-use, or alternative named, even though scan_token_safety and trace_funding_clusters are plausible substitutes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Payment options and local activation instructions. No wallet connection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It usefully discloses that no wallet connection is required, but omits whether the operation is read-only, what permissions are needed, and what the returned data looks like, which are important for a tool with no structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short fragments with no wasted words, front-loading the key content and the wallet constraint. It is appropriately sized for a simple zero-parameter info tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should provide enough context about what is returned. It names the content areas but does not describe the return format, structure, or level of detail an agent can expect, leaving a modest gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to document. The schema is empty and the description does not need to explain arguments, matching the baseline of 4 for parameter-free tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the resource contents (payment options and local activation instructions), making clear what information the tool provides. It does not explicitly differentiate from the sibling activate_pro_license tool, which could cause ambiguity for an agent deciding between retrieving information and performing activation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as activate_pro_license. The only contextual note is a constraint ('No wallet connection'), not usage direction, leaving the agent to infer the call context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free Solana or Base token risk heuristics with evidence and limitations.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | solana | |
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses that results are heuristic and include evidence and limitations, which sets expectations, but it does not state read-only behavior, rate limits, authentication needs, or whether the scan has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, front-loading the free scope and the two supported chains. Every phrase carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should more fully explain the required address input and what 'evidence and limitations' means in the response. As written, it leaves important invocation and interpretation gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The mention of Solana or Base loosely maps to the chain enum, but the required address parameter, its format, and the default chain value are never described, so the description does not compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (Solana or Base token) and operation (risk heuristics with evidence and limitations). It is clear enough to understand the tool's role, but 'heuristics' is slightly vague and no sibling tool is named to distinguish it from detect_block0_bundler or trace_funding_clusters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no when-to-use conditions, prerequisites, or alternatives. The word 'free' hints at a Pro/upgrade distinction but does not explicitly route the agent to get_pro_upgrade_info or another sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pro: Solana shared-funder heuristics for wallet owners. Base reports unsupported without an indexer.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | solana | |
| holderAddresses | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose two useful traits beyond the schema: this is a Pro-gated capability (relevant given siblings activate_pro_license and get_pro_upgrade_info) and Base coverage depends on an indexer. It says nothing about read-only vs mutating behavior, result format, or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no padding, and the Pro/Solana scope leads. The second sentence is cryptic enough that its brevity comes at some cost to comprehension, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and undocumented parameters, the description is far too thin. An agent gets no picture of what the returned clusters look like, how the heuristics behave, or the constraints on the address array.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain both parameters and does not. 'Solana shared-funder' loosely maps to the chain parameter and 'wallet owners' loosely to holderAddresses, but there is no mention of the 20-address maximum, required vs optional status, or address format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (shared-funder clusters for wallet owners) and constrains it to Solana, so an agent can roughly tell what it analyzes. But it states no verb ('trace' comes only from the name) and never says what a cluster is or what the caller receives, leaving the purpose vague rather than specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Base reports unsupported without an indexer' hints at a when-not condition for the non-default chain value, but the wording is ambiguous about whether Base ever works. No sibling tool (scan_token_safety, batch_audit_watchlist, etc.) is named as an alternative, so routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0activate_pro_licensebatch_audit_watchlistdetect_block0_bundlerget_pro_upgrade_infoscan_token_safetytrace_funding_clustersScored across 6 tools
Each tool has a fairly distinct target: free single-token scan, bundler detection, funding-cluster tracing, batch audit, and two licensing tools. The main ambiguity is between scan_token_safety and the Pro analysis tools, since an agent might not immediately know whether a risk scan already subsumes bundler/funding checks, but descriptions clarify the Pro/free split.
All names use snake_case with a leading verb (scan_, get_, activate_, detect_, trace_, batch_audit_), which is highly predictable. 'batch_audit_watchlist' is a slight deviation since 'batch' modifies the verb rather than being the verb itself, but it remains readable and consistent in style.
Six tools is well-scoped for a token-safety service with a free tier and a Pro tier. Each tool covers a distinct capability (scan, bundler detection, funding trace, batch audit, upgrade info, license activation) and none feels redundant or filler.
The surface covers the core lifecycle: free scanning, multiple Pro analyses, batch auditing, and license info plus activation. Minor gaps exist, such as no explicit license-status or deactivation check, but agents can work around this via get_pro_upgrade_info.
Solana on-chain intelligence — token scans, wallet profiling, bundle detection, 19 MCP tools.
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
Pre-trade token safety checks for AI agents on Solana and Base. x402 USDC per call, no key.