Loading ToolBench
Read-only MCP server exposing the o1.exchange DEX aggregator (live quotes + routing on Base) over stdio.
o1-mcp demonstrates solid tool definition quality with complete schemas, clear descriptions, and proper parameter typing. All 5 tools have explicit input schemas with typed parameters and descriptions. Tool names follow verb_noun convention (get_quote, list_supported_dexes, build_swap_transaction, execute_swap). Descriptions are substantive (100-250 chars), explaining WHAT the tool does and key constraints. However, some parameter descriptions lack actionable detail (e.g., 'slippageBps' lacks min/max bounds in description text), and output schemas are not formally documented. Error handling is present but generic. No critical security issues detected, the server correctly avoids accepting private keys and uses server-side configuration.
Fetch broadcast-ready, UNSIGNED swap calldata for a quoteId (POST /submit). This server never accepts a private key, never signs, and never broadcasts — you sign in your own wallet.
One-shot quote + broadcast-ready UNSIGNED calldata for a Base swap (POST /execute). Collapses /quote and /submit into one call. This server never signs or broadcasts — you sign in your own wallet. Pass token addresses or "ETH"; set useNativeIn when selling ETH.
Get a live DEX-aggregator swap quote on Base (o1.exchange). Read-only — no wallet or signing. Pass token addresses or "ETH". amountIn is in base units (wei). Returns a compact route summary + raw. Quotes expire in ~10s.
Check o1.exchange aggregator liveness (GET /health). No auth, no parameters. Returns { ok, raw }.
List the DEX venues (DexId enum) the o1 aggregator can route through on Base. No parameters.
Output schemas not formally documented. Tool descriptions state what is returned (e.g., 'Returns a compact route summary + raw') but do not specify the exact JSON structure, field types, or required fields. LLMs cannot reliably extract or chain results without explicit output schema.
Numeric parameter constraints not stated in descriptions. 'slippageBps' accepts 0..2000 but description does not mention bounds; 'timeBudgetMs' accepts 50..10000 but description omits range. LLMs may pass invalid values; validation errors will not be self-correctable without explicit constraints in text.
Error handling lacks recovery guidance. Tool descriptions do not explain what errors are possible, how to interpret them, or what the LLM should do next (retry, ask user, try alternative tool). Generic error responses will not guide agent recovery.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2025-06-18+ | v2 |
Parameter 'permit' (object type) lacks structure documentation. Description says 'Optional EIP-2612 permit payload' but does not specify required/optional fields within the object. LLMs cannot construct valid permit objects without a schema.
No pagination or result-limiting guidance. Tools like o1_list_supported_dexes do not document expected result size or whether pagination is needed. If DEX list grows large, response could bloat context window.