Provides tools for scoring Solana SPL token rug-pull risk from public on-chain data, including a free risk score and a paid full risk report via x402 USDC payments on Solana mainnet.
See the rug before it's pulled. Rugsight scores the rug-pull risk of any Solana SPL token from public on-chain data, and explains every flag. It is built for humans and for AI agents.
Free API: GET https://rugsight.rugsight.workers.dev/api/score/{mint} (score, grade, verdict, flag codes)
Paid API for agents (x402): GET https://rugsight.rugsight.workers.dev/api/v1/report?mint={mint}, 0.03 USDC per call on Solana mainnet. No API key, no signup.
Remote MCP server: https://rugsight.rugsight.workers.dev/mcp (streamable HTTP). Tools: get_token_risk_score (free) and get_token_risk_report (x402, 0.03 USDC).
Humans: the full report on the website costs 1 USDC (or the same value in SOL), paid with Solana Pay. Payments are crypto-only.
Discovery: /.well-known/x402, /openapi.json, /llms.txt, /.well-known/mcp/server-card.json
# free score for BONK
curl https://rugsight.rugsight.workers.dev/api/score/DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263MCP client config (any client that supports remote streamable-HTTP servers):
{ "mcpServers": { "rugsight": { "url": "https://rugsight.rugsight.workers.dev/mcp" } } }Not financial advice. Rugsight publishes automated technical analysis of public blockchain data. A good score does not mean a token is safe, and a bad score does not mean it is a scam. Do your own research.
Piece | Service | Cost |
API + static site | Cloudflare Workers + static assets | free tier |
Orders | Cloudflare D1 (SQLite) | free tier |
Cache (scores 5 min, reports 7 days, SOL price 2 min) | Cloudflare KV | free tier |
Chain data | Solana JSON-RPC: Helius free key, or any RPC | free tier |
Market data | DexScreener public API (all pools), falling back to Jupiter token API, then a last-good KV copy (<30 min); used for our own metrics only | free |
Payments | Solana Pay transfer requests, checked on-chain | network fee is paid by the buyer |
Agent payments | x402 v2 (v1 compatible) through the PayAI facilitator (1,000 free credits, no key) | free |
Related MCP server: soldefi-mcp
Each score starts at 100. Every risk flag subtracts points. Grades: A ≥ 85, B ≥ 70, C ≥ 50, D ≥ 30, F otherwise.
Area | Flags (points) |
Authorities |
|
Token-2022 extensions |
|
Holders: wallets only, excluding pools, programs and burn addresses |
|
Liquidity |
|
Age |
|
If holder data cannot be read (for example, tokens with millions of holders such as USDC, which RPCs refuse to rank), the result is marked confidence: "partial" and the grade is capped at B.
Data policy: we publish only metrics we compute ourselves: scores, flags, buckets and percentages. We do not pass on raw third-party data. For example, liquidity and volume appear as ranges, not as DexScreener's figures.
Method | Path | Description |
GET |
| Free basic score: score, grade, verdict, flag codes and confidence |
POST |
| Creates a 1-USD order. Returns a Solana Pay URL, a QR code, and status and report URLs |
GET |
| Order status. Checks the chain for a payment that carries the order's reference key |
GET |
| Solana Pay QR code |
GET |
| Full report. Returns |
GET |
| x402 pay-per-call full report (0.03 USDC). Also |
POST |
| Remote MCP server (streamable HTTP): |
GET |
| Discovery documents |
GET |
| Shows whether payments, x402 (and whether the treasury USDC account exists) and the RPC are configured |
Example:
curl https://<your-worker>/api/score/DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263An unpaid GET /api/v1/report?mint=… returns 402. The PAYMENT-REQUIRED header carries the base64 x402 v2 PaymentRequired (scheme exact, network solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp, 30000 base units of USDC to the treasury, fee payer = PayAI sponsor, Bazaar discovery extension). The body carries the x402 v1 form for older clients.
The client retries with PAYMENT-SIGNATURE (v2) or X-PAYMENT (v1).
The worker decodes the partially signed transaction and rejects it locally if the fee payer, the destination ATA, the mint or the amount is wrong. Then it calls the facilitator's /verify.
It builds the report. If that fails, it answers 503 and does not settle, so the payer is not charged.
It calls /settle, returns the report with PAYMENT-RESPONSE, and logs the settlement in x402_payments.
The treasury must own a USDC token account (TREASURY_USDC_ATA) before x402 transfers can land; /api/health reports x402PayToReady.
POST /api/orders creates a random reference public key and stores the order in D1.
The buyer's wallet opens solana:<TREASURY>?amount=..&spl-token=<USDC>&reference=<ref>. The spl-token parameter is left out for SOL payments.
GET /api/orders/:id calls getSignaturesForAddress(reference) and getTransaction. It accepts the order only if the transaction succeeded and the treasury's USDC token balance (or SOL balance) rose by at least the quoted amount.
orders.signature is UNIQUE, so one transaction can pay for only one order.
A SOL quote uses the SOL/USD price from DexScreener at order time and is rounded up.
npm install
npm run db:local # apply migrations/0001_init.sql to the local D1
npm run relay # see note below (port 8899)
npm run dev:local # http://localhost:8799
npm run typecheck
npm test # checks the payment verifier against real mainnet transactions (read-only)
npm run analyze -- <mint> # runs the scoring engine directly in NodeRPC note: the public endpoint api.mainnet-beta.solana.com blocks requests sent from Cloudflare Workers.
Those requests carry a CF-Worker header, and the endpoint answers 403.
It also rate-limits getTokenLargestAccounts (HTTP 429).
For local tests, test/rpc-relay.mjs forwards requests without that header.
In production, set HELIUS_API_KEY. A free Helius key is enough. You can also point SOLANA_RPC_URL at another provider.
Without a key, holder data is available only for Token-2022 tokens, such as new pump.fun launches. This comes from an account-scan fallback.
stdio/ is a small MCP server that talks over stdio. It's a thin client for the hosted API, so all analysis runs on the hosted service, and it holds no keys or wallets.
It exposes the same tools as the hosted /mcp endpoint:
get_token_risk_score: free. Calls GET /api/score/<mint>.
get_token_risk_report: 0.03 USDC per call via x402, settled by the hosted service. Without a payment, the tool returns the PaymentRequired object. To pay, retry the tools/call with _meta["x402/payment"] (an x402 v2 PaymentPayload), and the local server forwards it to the hosted /mcp.
cd stdio && npm ci
node index.js # speaks MCP over stdin/stdout
npm test # smoke test: initialize, tools/list, score for BONK, 402 for the reportClaude Desktop, Cursor, or any stdio MCP client:
{ "mcpServers": { "rugsight": { "command": "node", "args": ["/path/to/rugsight/stdio/index.js"] } } }Environment variables:
RUGSIGHT_API_URL: base URL of the API. Defaults to https://rugsight.rugsight.workers.dev, and you can point it at your own deployment.
RUGSIGHT_TIMEOUT_MS: request timeout. Defaults to 30000.
Docker: docker build -t rugsight-mcp . && docker run -i --rm rugsight-mcp. The image needs Node 18 or later. The Dockerfile uses Node 20.
wrangler.toml → [vars]; secrets via wrangler secret put)Var | Default | Notes |
|
| Receives every payment |
|
| Full report price |
|
| Quote validity. Payments that arrive late are still honoured |
| public mainnet | Ignored when |
| none | Needed in production |
|
| Set this to the deployed URL |
|
| x402 settings; tests: |
Rugsight runs entirely on the Cloudflare Workers free tier. Change TREASURY_ADDRESS, TREASURY_USDC_ATA and PUBLIC_BASE_URL in wrangler.toml to your own wallet and URL first, otherwise payments go to the Rugsight treasury.
npx wrangler login # Cloudflare account (free)
npx wrangler kv namespace create CACHE # copy the id into wrangler.toml
npx wrangler d1 create rugsight # copy database_id into wrangler.toml
npx wrangler d1 migrations apply rugsight --remote
npx wrangler secret put HELIUS_API_KEY
# set PUBLIC_BASE_URL in wrangler.toml to https://rugsight.<subdomain>.workers.dev
npx wrangler deploy
curl https://rugsight.<subdomain>.workers.dev/api/healthSee migrations/0001_init.sql (also copied as schema.sql).
It has two tables: orders (Solana Pay orders) and x402_payments (a settlement log for pay-per-call).
MIT. Contact: yunare-qwerng+rugsight@mail.grokbot.com · X: @rugsightapp
Full Rugsight risk report: every flag explained, top-20 holder breakdown, liquidity, 24h volume, pool age. Costs 0.03 USDC on Solana per call, paid with x402 on the hosted service: call without payment to receive the PaymentRequired object, then retry with _meta["x402/payment"] (x402 v2 PaymentPayload). Not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Solana token mint address (base58) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint and openWorldHint annotations, the description discloses that each call costs 0.03 USDC, is paid via x402 on the hosted service, and requires a two-step payment handshake. That is meaningful behavioral context an agent needs before invoking it.
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 report contents are front-loaded and the payment flow follows in a compact sequence. The only minor boilerplate is 'Not financial advice', but overall the description is efficient.
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 is no output schema, and the description compensates by listing the report contents, including flag explanations and holder/liquidity metrics. The payment mechanics are also covered, though the exact response structure is not described.
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 coverage is 100% for the single mint parameter, so the schema already documents the required input. The description adds no additional meaning about the mint parameter or its expected format, so baseline 3 applies.
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 clearly states it returns a full Rugsight risk report and enumerates its contents (flag explanations, top-20 holders, liquidity, volume, pool age). It implicitly distinguishes itself from the sibling get_token_risk_score via 'Full ... report', but does not name the sibling explicitly.
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?
It gives a clear payment invocation flow (call without payment, then retry with _meta['x402/payment']), which is important usage context. However, it never explicitly says when to choose this full report over the sibling get_token_risk_score, leaving that comparison implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quick rug-risk check for a Solana SPL / Token-2022 token: 0-100 score, A-F grade, verdict and risk flag codes (mint & freeze authority, Token-2022 extensions, holder concentration, liquidity). Free, no payment needed. Calls the hosted Rugsight API. Automated technical data, not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Solana token mint address (base58) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and open-world, and the description adds real context beyond them: the output shape and scale, that it hits a hosted Rugsight API, that there is no cost, and an explicit 'not financial advice / automated data' caveat. It does not mention rate limits, latency, or behavior on an invalid or non-existent mint.
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 dense paragraph that front-loads purpose and resource, then output shape, then cost, then disclaimer — every sentence carries information. The A-F grade plus 'verdict and risk flag codes' is slightly redundant phrasing but not wasteful.
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 is no output schema, so the description must describe returns, and it does: score range, grade scale, verdict, and the categories behind the flag codes (mint/freeze authority, Token-2022 extensions, holder concentration, liquidity). For a single-parameter read tool with annotations, the remaining gaps (error cases, rate limits) are minor.
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?
With a single required parameter at 100% schema coverage, the schema already defines 'mint' as a base58 Solana mint address. The description adds only that both SPL and Token-2022 mints are supported, which is a useful but modest increment over the schema.
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?
Specific verb ('quick rug-risk check') plus a precise resource scope (Solana SPL / Token-2022 token) and an enumeration of what comes back (0-100 score, A-F grade, verdict, risk flag codes). It does not name the sibling get_token_risk_report, so the quick-vs-full-report distinction must be inferred from the word 'quick' and the free-tier note.
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?
'Free, no payment needed' implies this is the cheap screening path versus the paid report sibling, but the description never states when to prefer get_token_risk_report or what extra depth it buys. Usage is implied only, with no explicit routing rule or exclusions.
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.
v0.1.0get_token_risk_reportget_token_risk_scoreScored across 2 tools
Both tools assess token rug risk, so the underlying purpose overlaps, but the descriptions make the boundary clear: one is a free 0-100 score/grade snapshot, the other is a paid full report with holder and liquidity detail. An agent can reliably pick based on depth and payment willingness, though the near-identical names invite a quick double-check.
Both names follow the same get_token_risk_* snake_case verb_noun pattern with a shared prefix, making the pair read as a deliberate, predictable family. No mixing of conventions.
Two tools is on the thin side even for a narrow risk-scoring service; the surface is essentially one capability offered at two depths. It is defensible for a focused hosted API, but leaves little room for adjacent operations.
The core domain — token risk assessment — is covered at both summary and detailed levels, including flags, holders, liquidity, and pool age, so there are no dead ends for the primary workflow. Minor gaps exist: no batch/multi-token check, no historical or cached report retrieval, and no way to list or search tokens.
Solana token/wallet rug-risk scoring. Free scan; $2 SOL unlocks full wallet report. No signup.
Solana token rug check before you buy: SAFE/CAUTION/DANGER from chain state, paid per call via x402.
Solana token rug/honeypot checks: free quick check; full score paid via x402 (USDC Solana/Base).
Solana address risk grades and token scans for AI agents. Pay-per-call via x402 (USDC on Base).