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

Swap route on Base (free)

get_swap_route

Read-only

Free route data: the best swap route on Base (or Ethereum) for a token you already checked with token_risk — quote, minimum out, approval target and, with taker, the unsigned transaction you sign and send yourself. Technical data and risk-analysis service only: no custody, no order execution, no investment advice. Disclosed: the 0.5 % integrator fee is a technical API provisioning fee for computing the route data, deducted by the aggregator inside the swap and sent to Angel's wallet; buy_amount is already net of it. Run token_risk on buy_token first. After: approve the spender if approval is set, then send the transaction from your own wallet.

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": {
      "sell_token": "<sell_token>",
      "buy_token": "<buy_token>",
      "sell_amount": "<sell_amount>"
    },
    "name": "get_swap_route"
  }
}

Input Schema

Name	Required	Description
`chain`	No
`taker`	No	your wallet, to get the unsigned transaction
`buy_token`	Yes	0x address or USDC, WETH, ETH
`sell_token`	Yes	0x address or USDC, WETH, ETH
`sell_amount`	Yes	integer in the token's smallest unit (1 USDC = 1000000)
`slippage_bps`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds the context those annotations cannot carry, notably that the tool never executes an order and that the returned buy_amount is already net of a 0.5% integrator fee routed to a third-party wallet. It explains the exact mechanism of the fee (deducted by the aggregator inside the swap), and clarifies that the tool is data-only with no custody.

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?

The core capability and prerequisite are front-loaded, and the disclosure and next-step sentences are ordered sensibly. It is dense, with some legal boilerplate (no custody/no advice) that could be trimmed but is defensible for a financial-data tool.

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?

For a six-parameter tool with no output schema, the description still communicates the return shape (quote, minimum out, approval target, unsigned transaction) and the full call sequence before and after. Fee handling and the no-execution boundary are disclosed, leaving no material gap for an agent to call 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 67%, and the description adds real meaning for taker (your wallet, used to get the unsigned transaction) and explains what buy_amount reflects after the fee. It also establishes the token_risk precondition for buy_token. slippage_bps and chain get no explanation beyond the schema enum and min/max bounds.

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 concrete verb and resource: it returns the best swap route on Base or Ethereum, and enumerates the payload (quote, minimum out, approval target, and with taker an unsigned transaction). It also distinguishes itself from the sibling token_risk, which it positions as a prerequisite rather than a substitute.

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

Usage Guidelines5/5

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

Gives an explicit prerequisite (run token_risk on buy_token first) and a conditional rule for the taker parameter (supply it to receive the unsigned transaction). It also spells out the follow-up workflow: approve the spender if approval is set, then send the transaction from your own wallet. No directly comparable alternative exists among the siblings.

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.