Bot Bazaar

Pre-Flight Base Swap & Unsigned Calldata Linter ($0.02)

defi_unsigned_swap_calldata_linter

Idempotent

[Paid x402 / X-Bazaar-Key: 0.02 USDC] Pre-Flight Base Swap Heuristic & Unsigned Calldata Linter: screens token/router/hook addresses against OFAC SDN, checks Uniswap v4 hook-delta flags and slippage bounds, and formats an unsigned ERC-20 approve + swap transaction template (integrator_fee_bps: 0, never signs or broadcasts). Also available at aliases /v1/x402/defi/pre-flight-swap-audit and /v1/swap/build-quote.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "defi_unsigned_swap_calldata_linter"
  }
}

Input Schema

Name	Required	Description
`token_in`	No	Input ERC-20 token address on Base
`token_out`	No	Output ERC-20 token address on Base
`dex_router`	No	Target Base router (uniswap_universal_router, aerodrome_v2, odos_v2, zerox_settler)
`from_address`	No	Caller unhosted wallet 0x address
`slippage_bps`	No	Max slippage tolerance in bps (e.g. 50)
`amount_in_atomic`	No	Input amount in atomic token units

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 28, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already cover non-destructiveness and idempotency, but the description adds critical operational context: paid x402 access at 0.02 USDC with X-Bazaar-Key, heuristic screening, integrator_fee_bps fixed at 0, and the fact that it never signs or broadcasts. This is substantial behavioral disclosure beyond the structured fields.

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 purpose and safety behavior are front-loaded in a dense but usable sentence. The trailing alias list and repeated price/title text add minor redundancy without obscuring the main point.

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

Completeness4/5

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

For a complex six-parameter tool with no output schema, the description covers purpose, auth/payment, safety posture, and the fact that output is an unsigned template. Return shape and error behavior are not described, but the lack of an output schema lowers that burden.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already explains all six parameters. The description loosely maps screening to token/router/hook addresses and slippage checks to slippage_bps, but adds no syntax, constraints, or examples beyond what the schema provides.

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

Purpose4/5

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

The description states a specific resource and action set: a pre-flight Base swap heuristic and unsigned calldata linter that screens addresses, checks hook/slippage conditions, and formats an unsigned approve+swap template. This is clear, but it does not explicitly distinguish the combined workflow from overlapping siblings such as defi_uniswap_v4_hook_delta_audit or ofac_check.

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?

The 'Pre-Flight' framing gives a clear usage context: run this before executing a Base swap. It does not state when not to use it or which sibling to use for standalone OFAC or hook-delta checks, so alternative routing is left implicit.

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

All Bot Bazaar 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.

Resources

Need Help?