What changed in the description

honeypot-check gives an agent a buy/sell simulation result for a token before it attempts a swap. Its rewritten description now names that job explicitly: “token honeypot check” and “pre-swap sell-block check.”

The closing instruction previously read:

Use before every swap to detect sell-blocking risk.

It now reads:

Use it as a token honeypot API or pre-swap sell-block check.

That wording appears in the endpoint’s description field in bankr.x402.json. The source change also updates the description exposed through the edge-market MCP package.

The price hasn't moved. It's still 0.05 USDC per call, with currency: "USDC", network: "base", and paymentScheme: "exact". Payment uses x402 on Base mainnet. This change leaves the request schema and HTTP method intact.

Give your router the new wording

Tool descriptions help an LLM choose what to call. A request such as “check this token for sell restrictions” should lead a router toward honeypot-check when it needs evidence from a buy/sell simulation.

So refresh any cached description you copied into your agent’s tool catalog. If you're maintaining a separate routing prompt, name the task directly: use honeypot-check for token honeypot checks or a pre-swap sell-block check.

Existing callers can keep their request bodies.

The endpoint accepts POST. Its required input is token_address, a 0x-prefixed, 20-byte EVM contract address. The optional chain defaults to base; the input enum also accepts ethereum and bsc. The revised prose mentions Base and Ethereum, so use the schema when validating accepted chain values.

Here's the HTTP request shape. Replace the address placeholder before sending: 

POST https://x402.agentutility.ai/honeypot-check
Content-Type: application/json

{
  "token_address": "<0x-prefixed token contract address>",
  "chain": "base"
}

Send it through your x402-capable client to complete payment. Choosing a token’s chain doesn't change the registry’s Base payment network.

Read the returned fields carefully

The description rewrite doesn't repair an existing mismatch between the catalog’s output descriptions and the current handler.

The catalog describes a simulation success flag, but the handler doesn't return that flag. It places the honeypot verdict at simulation.is_honeypot. The risk object contains level and reasons, rather than the verdict described in the catalog.

That matters for generated clients. Several catalog output properties are typed as strings even though the handler returns objects. Check your parser against those object shapes before relying on schema-generated accessors.

For example, this illustrates the field access, not a captured response: 

const verdict = result.simulation.is_honeypot;
const sellTaxPct = result.simulation.sell_tax_pct;
const reasons = result.risk.reasons;

Tax fields are optional. Keep an absent sell_tax_pct distinct from a returned value of zero.

And treat is_honeypot: false carefully: the handler sets it to false whenever the underlying result isn't explicitly true, including when that verdict is absent. Without an exposed success flag, false alone doesn't establish that a sell simulation completed successfully.

Where it fits in an edge-market workflow

An edge-market agent evaluating a token needs evidence about sell restrictions before it signs a transaction. The revised description gives the router a more direct match for that request, while preserving the 0.05 USDC call price.

But the caller still needs its own decision policy. Record the token address with the returned chain so the result stays attached to the contract you checked. Preserve missing tax values as unknown, and keep the returned reasons available for human inspection.

For your routing checks, use a prompt such as “check this Base token for sell-blocking behavior before the proposed swap.” Verify that it selects honeypot-check and supplies token_address. Then give the response parser a fixture with no sell_tax_pct and confirm that your application doesn't turn that missing value into a zero-tax claim.