Base Token Audit — ERC-20 honeypot check and swap route data

Honeypot and rug-pull check for an ERC-20 before swap or approve

token_risk

Read-only

Honeypot and rug-pull check for an ERC-20 on Base or Ethereum before a swap, approval or signature, read straight from the contract: upgradeable proxy (EIP-1967, beacon, clone), owner powers in the bytecode (mint, pause, blacklist, fee or max-tx setters, trading switch, burn from any address), owner renounced or active and the owner's share of supply; known issuers labeled. Risk low, medium or high with reasons. Signals, not investment advice. 0.99 USDC base (new payers 0.99, >10 payments 0.693; 20 pack calls). After: gas-window before you trade on that chain (the result's next field has the exact call).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "token": "<token>"
    },
    "name": "token_risk"
  }
}

Input Schema

Name	Required	Description
`chain`	No
`token`	Yes
`payment_tx`	No	Hash of a USDC transfer on Base to payTo (≥ the price, ≤ 72 h old) instead of an x402 signature.
`bundle_token`	No	Token from buy_signal_pack, buy_subscription (pro/desk) or buy_enterprise instead of paying per call.
`payer_address`	No	Wallet you pay from: the payment-required error quotes your tier (0 payments base price (new-payer surcharge paused), 1-10 base, >10 -30 %) and, from the third payment, an upgrade with your own spend.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description goes beyond that by disclosing pricing and tier mechanics, what is read from the contract (EIP-1967 proxies, owner powers), the output shape (low/medium/high risk with reasons) and a non-advice disclaimer. However, it never states latency, failure modes, or what happens for an unverified/unreachable contract.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the core sentence is a dense run-on stacking contract features and pricing tiers. The trailing 'After: gas-window...' note is useful routing but awkwardly phrased; nearly every clause carries information, so little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With five parameters, one required, no output schema and no nested objects, the definition covers purpose, chains, payment options, expected risk output and the next recommended call. That is sufficient for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 60%, and the description compensates by clarifying the token domain and pricing tiers (0.99 base, 0.693 above 10 payments, 20-pack) that map onto the payment parameters. It still does not explain payment_tx, bundle_token or payer_address semantics, though the schema partially documents the latter two.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (honeypot and rug-pull check for an ERC-20) plus the chain scope (Base or Ethereum) and the moment it applies (before swap, approval or signature). An agent can distinguish it from siblings like preflight or validate_setup without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly frames the use case as pre-trade/pre-approval, and names the follow-up sibling gas-window with the condition 'before you trade on that chain'. No explicit exclusion of alternative tools, but the usage context is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Base Token Audit — ERC-20 honeypot check and swap route data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.