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., "@rug-check check token 0x4ed4e862860bed51a9570b96d89af5e1b0efefed on base"
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.
On-chain rug-pull & honeypot risk screen for ERC-20 tokens — for AI agents and traders.
Give it a token address and get a SAFE / CAUTION / HIGH-RISK verdict (0–100 score) in one call, built entirely from live public-RPC reads — no API key, no node, no signup.
rug-check is an automated on-chain risk screen, not financial advice or a safety guarantee. It pattern-matches deployed bytecode and reads chain state; it cannot catch every scam (off-chain admin keys, novel honeypots) and may flag benign contracts. Always do your own research.
An AI coding/trading agent that "just reads the chain" does not know:
Which dangerous functions the token's deployed bytecode exposes — mint, blacklist, pause, setFees, setMaxTx — the levers used to trap or dilute holders.
Whether ownership is renounced, or an active owner can still call those powers after you buy.
How concentrated supply is in the owner/deployer wallet (dump risk).
Whether a DEX liquidity pair exists, how deep it is, and whether the LP tokens are locked or burned — the single thing that decides if the deployer can pull all liquidity (the literal "rug pull").
rug-check ABI-encodes and batches all of that, decodes the bytecode, scores it, and returns one verdict.
Related MCP server: safeagent-token-safety
Check | What it tells you |
Owner powers | scans runtime bytecode for |
Ownership | renounced vs active owner ( |
Concentration | % of total supply held by the owner wallet |
Liquidity | UniswapV2/Pancake pair reserves vs wrapped-native, depth, thin-liquidity flag |
LP lock/burn | % of LP supply in burn address or known lockers (Pinksale, Unicrypt, Team.Finance…) |
Proxy | EIP-1967 upgradeable-proxy detection (behaviour can change post-launch) |
Chains: Ethereum, Base, BSC, Polygon, Arbitrum.
{
"mcpServers": {
"rug-check": { "command": "npx", "args": ["-y", "rugshield-mcp"] }
}
}Tools:
rug_check_token — { chain, address } → full risk report.
rug_check_many — up to 10 { chain, address } → batch verdicts.
Or connect over HTTP at POST /mcp.
GET /check?chain=base&address=0x4ed4e862860bed51a9570b96d89af5e1b0efefed
GET /check?chain=ethereum&address=0x6b175474e89094c44da98b954eedeac495271d0fRate-limited 30/h/IP.
The /pro/* routes are gated by x402. Your agent pays $0.25 USDC per call automatically — no sign-up, no API key. Settles on-chain (Base) to the operator wallet.
GET /pro/check?chain=base&address=0x...
GET /pro/check_many?tokens=base:0x..,bsc:0x..Discovery: GET /openapi.json (with x-payment-info) and GET /.well-known/x402.
npm install
npm run build
npm run test:engine # offline unit tests + live on-chain sanity checks
npm run dev:http # local HTTP server on :8080 (payments OFF unless configured)
npm run dev:mcp # stdio MCP serverMIT © rug-check
Run rug_check on up to 10 tokens at once. Pass an array of {chain,address}. Returns the verdict and score for each so an agent can screen a watchlist or a batch of candidate tokens in one call.
| Name | Required | Description | Default |
|---|---|---|---|
| tokens | Yes | Up to 10 {chain,address} pairs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return behavior ('Returns the verdict and score for each'), but lacks details on error handling, rate limits, or 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?
Two sentences, no wasted words. Front-loaded with action and key constraints.
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?
Given the tool has one parameter and no output schema, description adequately explains input structure and output type. Could add more on output format or potential errors, but sufficient for a batch 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 coverage is 100%, so description adds little beyond schema. It repeats structure ('Pass an array of {chain,address}') and notes max 10 items, already in schema. Does not explain field semantics further.
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?
Description clearly states 'Run rug_check on up to 10 tokens at once' - specific verb and resource. Differentiates from sibling 'rug_check_token' by indicating batch capability.
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 examples of when to use: 'screen a watchlist or a batch of candidate tokens in one call'. Implicitly suggests using rug_check_token for a single token, but does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess whether an ERC-20 token is a likely SCAM / rug pull BEFORE buying or interacting with it. Returns a risk score (0-100) and verdict (SAFE / CAUTION / HIGH RISK) built from LIVE on-chain reads: dangerous owner powers found in the token's deployed bytecode (mint, blacklist, pause, set-fee, set-max-tx), whether ownership is renounced, what % of supply the owner holds, whether a DEX liquidity pair exists and how deep it is, and whether the LP tokens are locked/burned (so the deployer can't pull liquidity). Use this whenever a user or agent is about to trade, approve, or add liquidity for an unfamiliar token. Chains: ethereum, base, bsc, polygon, arbitrum.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Chain: ethereum, base, bsc, polygon or arbitrum. | |
| address | Yes | The token contract address (0x...). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details the on-chain checks performed (dangerous owner powers, ownership renounced, owner supply, DEX liquidity, LP lock/burn), offering transparency about data sources. However, it does not disclose potential limitations such as API rate limits, error handling, or behavior for non-ERC-20 tokens.
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 sentences, front-loaded with the tool's main purpose and outputs, followed by methodology and usage context. Every sentence adds value; no wasted words.
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?
Despite no output schema, the description adequately specifies the return values (risk score 0-100, verdict) and explains the logic. It is sufficient for a tool with two simple parameters, though it could benefit from noting the exact response format.
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 100%, so the schema already documents both parameters (chain and address). The description reiterates the chain options and address format without adding new semantic meaning beyond what the schema provides. Baseline of 3 is appropriate.
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 the tool assesses whether an ERC-20 token is a likely scam/rug pull, with specific outputs (risk score 0-100 and verdict). It also names the sibling tool 'rug_check_many', which implies this tool checks a single token, distinguishing its purpose.
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 description explicitly recommends using this tool 'whenever a user or agent is about to trade, approve, or add liquidity for an unfamiliar token,' providing clear context. It does not explicitly mention when not to use it or contrast with alternatives beyond naming the sibling, but the usage guidance is still strong.
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.1rug_check_manyrug_check_tokenScored across 2 tools
The two tools have clearly distinct purposes: one for batch checking up to 10 tokens, the other for individual token assessment. No overlap.
Both tools follow a consistent 'rug_check_' prefix with descriptive verbs ('many' vs 'token'), all in snake_case.
With only 2 tools, the count is minimal but perfectly scoped for the domain of rug checking, covering both individual and batch needs.
The tool set covers the primary use case (assessing token risk) with both single and batch modes, leaving no obvious gaps for the intended purpose.
Honeypot detection & token risk scan for ERC-20s. Risk score 0-100, tax, source verification.
Instant rug-check for any EVM or Solana token, distilled to one clear 0-10 risk verdict.
Rug pull risk and on-chain forensics for tokens on Solana, Ethereum, Base and Robinhood.
Pre-trade token safety check for AI agents. Simulates a sell before you buy, then returns one low/medium/high/unknown verdict with the signals behind it: sellability, buy/sell tax, liquidity depth, pair age, same-ticker impersonation, owner powers from bytecode. Ethereum, BSC, Base, Solana. Fail-closed - a check that cannot run answers unknown, never low. Publishes its own measured error rate with the benchmark harness in the repo. Free, no signup, no API key, MIT.
