Rug check & honeypot flags for Base/Solana tokens. Free preview; full $0.0009/token via x402.
Scored across 2 tools
check_token and check_token_risk are explicitly described as the same operation, differing only in whether chain+address is spelled out. An agent has no basis to choose between them, and both funnel to the identical x402 endpoint. This is pure duplication rather than two distinct capabilities.
Both names are snake_case verb_noun, so the convention itself is consistent. However, the differentiating suffix 'risk' carries no semantic distinction from the base verb 'check', making the pair read as an accidental clone rather than a deliberate naming scheme.
Two tools is thin for a server, and since they are functionally identical the effective surface is a single tool. A single-purpose risk-check server can legitimately be small, but offering a duplicate makes the count feel padded rather than scoped.
The domain supports single-token previews, full paid reports, and a batch endpoint (POST /v1/risk for 1-10 tokens) mentioned only in prose, yet no tool exposes batch checking or the full report retrieval. Agents hitting a multi-token screening need will have no path forward.
Token risk check (rug check, honeypot, scam token, memecoin / pump.fun safety) for one Base or Solana token. Free tool: returns risk_level, pass/warn/fail counts and 4 headline flags with raw values, plus the x402 URL for the full report ($0.0009 USDC on Base: GET /v1/check?token=chain:address; cheapest single-token x402 risk check we've found, vs $0.00098-$0.02 for others we checked, Oct 23 2026).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | ||
| token | No | chain:address, e.g. solana:<mint> or base:0x... | |
| address | No | token contract (Base) or mint (Solana) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, it discloses key behavior: free call, returned fields (risk_level, pass/warn/fail counts, four headline flags), and paid report endpoint/price. It omits auth/rate-limit/side-effect details, but the read-only nature is strongly implied by 'check' and the output disclosure is substantial.
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?
Purpose is front-loaded and the return/cost details are useful, but the single run-on sentence packs in promotional price comparison and a date that do not help an agent call the tool. It is informative but overstuffed.
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?
Covers purpose, output summary, and pricing, which matters because there is no output schema. Still missing sibling differentiation and clear guidance on combining chain/token/address means the definition is not fully complete for invocation.
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 67%, and the description mainly restates token format ('token=chain:address') already documented in the schema. It does not resolve why all three params are optional or when to use token vs address, leaving invocation ambiguity.
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 verb and resource—token risk check—and enumerates risk types and scope (one Base or Solana token). It does not distinguish from the near-identical sibling check_token_risk, so selection between them remains ambiguous.
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?
Describes free summary use and points to a paid x402 full-report URL, implying when the free check is sufficient. It never explicitly compares this tool with sibling check_token_risk or states when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Same as check_token with explicit chain + address: free token risk preview (rug check / honeypot / scam screen) for one Base or Solana token. Full report via x402: $0.0009 per token (GET /v1/check) or $0.015 for 1-10 tokens (POST /v1/risk).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | ||
| address | Yes | token contract (Base) or mint (Solana) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose key traits: the call itself is a free preview with limited scope, and a full report requires x402 payment at two distinct price points and endpoints. It does not describe rate limits, failure modes, or what the preview actually returns versus the paid report.
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: the first states scope and the preview/paid distinction, the second states costs and endpoints. Zero filler, and the core capability is front-loaded before pricing detail.
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 two-parameter tool with no annotations and no output schema, the description covers cost and scope but leaves the return shape entirely unspecified — an agent cannot tell what a "risk preview" yields, which matters since there is no output schema to fall back on.
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 50% — address is documented in the schema and chain is an enum. The description corroborates the chain semantics by naming Base and Solana, but adds no format or constraint detail beyond what the schema already encodes.
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?
It names a concrete resource and outcome: a free token risk preview covering rug check, honeypot, and scam screening for exactly one Base or Solana token. The contrast with the sibling is stated as "explicit chain + address," which tells an agent what differs structurally, though "Same as check_token" leans on a tool the agent may not have inspected.
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 phrase "same as check_token with explicit chain + address" implies the selection rule (use this when you supply chain and address directly), but it never states when to prefer check_token or when this tool is not appropriate. The pricing tiers give useful cost context but are not usage guidance.
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.
check_tokencheck_token_riskSolana token rug/honeypot checks: free quick check; full score paid via x402 (USDC Solana/Base).
Real-time token contract safety scanner and honeypot auditor via x402 on Base.
Base token safety: one-call verdict, risk score, rug check, holders, momentum. x402 + free demo.
Free token risk check (Base/Solana) + info on paid x402 reports. Not financial advice.
Add one secure layer between your agents and this server.