Provides pre-trade risk screening for EVM token contracts on Ethereum, including honeypot/tax/owner flags, LP-lock state, mint and freeze authority, transfer fee/hook checks, holder concentration, liquidity depth, wash-trade signals, and a final verdict.
Provides pre-trade risk screening for EVM token contracts on Polygon, including honeypot/tax/owner flags, LP-lock state, mint and freeze authority, transfer fee/hook checks, holder concentration, liquidity depth, wash-trade signals, and a final verdict.
Provides pre-trade risk screening for Solana SPL mints, including honeypot/tax/owner flags, LP-lock state, mint and freeze authority, transfer fee/hook checks, holder concentration, liquidity depth, wash-trade signals, and a final verdict.
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., "@100pro-token-risk Screen 0x1a2b...9c0d on base for token risk"
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.
Pre-trade risk screening for EVM token contracts and Solana SPL mints, exposed as a remote MCP tool. Honeypot/tax/owner flags, LP-lock state, mint & freeze authority, transfer fee/hook, holder concentration, liquidity depth, wash-trade signals — ending in a one-line Verdict.
Endpoint: https://x402.rendraputra.dev/mcp (MCP streamable HTTP, JSON-RPC 2.0)
Tool: token_risk_screen (token, chain) — read-only, up to 5 comma-separated addresses per call
Chains: base, ethereum, bsc, polygon, arbitrum, solana
Price: $0.10 USDC per single token, $0.25 for a 2-5 token batch, on Base, paid with
x402 v2 — no account,
no API key, no subscription. An unpaid call answers HTTP 402 with the payment challenge; pay it and
retry. Free metadata: /llms.txt,
/openapi.json,
/.well-known/x402.
{
"mcpServers": {
"100pro-token-risk": {
"type": "http",
"url": "https://x402.rendraputra.dev/mcp"
}
}
}Related MCP server: contract-auditor
Some clients only speak stdio. This tiny proxy forwards initialize, tools/list and tools/call
to the remote endpoint (stdlib only, no dependencies):
{
"mcpServers": {
"100pro-token-risk": {
"command": "python3",
"args": ["/absolute/path/to/100pro_mcp.py"]
}
}
}or straight from the repo, if you use uv:
{
"mcpServers": {
"100pro-token-risk": {
"command": "uvx",
"args": ["--from", "git+https://github.com/rndrpp/100pro-mcp", "100pro-mcp"]
}
}
}A markdown report per token, e.g.:
## 0x8335…2913 (base)
**Verdict: PASS — no blocking risk signal found.**
...If the call is unpaid the server answers with the x402 payment challenge (HTTP 402). Pay $0.10 USDC
(single token) or $0.25 (2-5 token batch) on
Base to the payTo in the challenge and retry; the response carries a PAYMENT-RESPONSE receipt
naming the settled transaction.
Free scanners are the product being sold elsewhere: rate-limited, delay-baiting, or an upsell funnel. This one is a single priced call with a fail-closed guarantee — the report is generated and returned only after the USDC transfer is confirmed on Base, and every settle attempt is logged with the on-chain verdict.
Discovery: https://x402.rendraputra.dev/llms.txt
x402 protocol: https://www.x402.org
MIT licensed.
100pro_mcp.py — repo-root entry point (python3 100pro_mcp.py, and the file container
checkers execute after cloning); it bootstraps pro100/bridge.py.
pro100/bridge.py — the actual stdio bridge: answers initialize / tools/list locally
(so introspection needs no network) and forwards tools/call to the hosted endpoint.
pyproject.toml — packages pro100, console script 100pro-mcp (so uvx --from git+https://github.com/rndrpp/100pro-mcp 100pro-mcp works).
Python 3.9+, standard library only — nothing to install for the plain-script path.
Pre-trade risk screen for an EVM token contract or a Solana SPL mint (Base, Ethereum, BSC, Polygon, Arbitrum, Solana): honeypot/tax/owner flags, LP-lock state, mint & freeze authority, holder concentration, liquidity depth, wash-trade signals, and a final Verdict line. Up to 5 comma-separated tokens per call. $0.10 USDC for one token, $0.25 for a 2-5 token batch, on Base via x402 v2 — no account, no API key. An unpaid call answers HTTP 402 with the payment challenge; sign it and retry with the payment under params._meta['x402/payment'].
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Optional; inferred from the address shape when omitted | |
| token | Yes | Contract address (0x...) or Solana mint; up to 5 comma-separated |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly/openWorld/idempotent, and the description adds substantial non-obvious behavior: the x402 payment model, the HTTP 402 challenge on unpaid calls, and the required retry with params._meta['x402/payment']. It also summarizes the verdict-style output, which is useful context not present in the 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?
Every sentence carries information: purpose and output list, batch size, pricing/payment, and retry behavior. The risk attributes are grouped in a colon-delimited list after the purpose, making the key content scannable regardless of the description's length.
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 paid, multi-chain tool with no output schema, the description covers chains, input limits, pricing, auth, payment retry, and the main output categories, and it explicitly mentions a final Verdict line. It could specify the verdict format more concretely, but it gives an agent enough to invoke the tool and interpret the high-level result.
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% and both token and chain are already described, including batch limit and chain inference, so the description mostly restates those details. Its only incremental parameter-related detail is the x402 payment key under params._meta, which is valuable but sits outside the schema properties; the high schema coverage makes the baseline 3 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 opens with 'Pre-trade risk screen' and names the exact resource (EVM token contract or Solana SPL mint), followed by a concrete list of outputs (honeypot/tax/owner flags, LP-lock state, holder concentration, liquidity depth, wash-trade signals, Verdict). This gives a specific verb+resource and leaves no ambiguity about what the tool evaluates.
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 are no sibling tools, so no explicit alternative routing is needed, but the description clearly frames when it applies: pre-trade screening, supported chains, a 5-token batch limit, and a paid-call caveat. It provides clear context while stopping short of explicit 'do not use for X' 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.0token_risk_screenScored across 1 tool
Only one tool exists, so there is no possibility of overlapping or confusable tools. The tool's purpose is clearly and uniquely defined.
With a single tool, there are no naming conflicts or mixed conventions. 'token_risk_screen' is a clear, descriptive snake_case name.
Although one tool is minimal, it is comprehensive for the server's focused purpose of token risk screening. The scope is narrow enough that a single well-designed tool is reasonable.
The tool covers the core risk-screening dimensions: honeypot/tax/owner flags, LP-lock, mint/freeze authority, holder concentration, liquidity depth, wash-trade signals, and a verdict. Multi-token batching and multi-chain support further round out the surface.
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 checks for AI agents on Solana and Base. x402 USDC per call, no key.
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.
