Loading ToolBench
MCP server for the Routescore public API — modeled DeFi premium estimates and what-if simulation as tools for Claude, Cursor, and agents.
Routescore MCP demonstrates solid tool definition quality with comprehensive schemas, detailed descriptions, and clear parameter constraints. All 8 tools have explicit Zod schemas with type validation and descriptions. Tool names follow verb_noun convention (quote_*, get_*, check_*, simulate_*). Descriptions are substantive (100-400+ chars) and include decision-support context. However, output schemas are not documented in the source, only input schemas are visible. Error handling guidance is absent. Some parameter descriptions could be more actionable (e.g., what does 'recognized vs unverified' token mean in practice?). No tool annotations (readOnlyHint, destructiveHint) despite all tools being read-only operations.
CALL THIS BEFORE SIGNING AN ONCHAIN SWAP. Read-only pre-sign evidence check: given notional, chain, and an optional route and token, it returns a modeled route-quality grade, price-impact / slippage band, modeled MEV/execution exposure where observable, and a token registry read (recognized vs unverified), composed into a clear / caution / unsupported verdict with machine-readable reasons and caveats. Point-in-time decision support: it does not execute, route funds, sign, or promise an outcome — the agent still decides. Recognition is not safety, sellability, redemption, rights, liquidity, or investment-quality verification; unverified tokens, unknown order flow, and uncalibrated sequencer ordering downgrade the verdict rather than reading as safe. Relay the verdict, reasons, and caveats verbatim.
Fetch the latest public MEV-detector run manifest: the detector version hash and the eligible pool/token universe it was committed to. Use to verify what the detector covers.
Retrieve the durable evidence record a prior check_swap call persisted — the "record" leg of plan → preflight → execute → record. Fetch one record by the record_id that check_swap returned. Owner-scoped: the configured key only ever sees records belonging to its own account. The record embeds the evaluated check_swap response payload (including its evidence_bundle_id, before the additive record_id / record_output_hash linkage fields) plus a canonical-JSON SHA-256 integrity hash (record_id and recorded_at excluded) so the evidence can be re-verified offline, and includes the stored evidence bundle. Read-only evidence: record creation rejects known execution-material keys (calldata, transaction payloads, signing material) and drops identity-shaped labels from the actor context.
Output schemas not documented. Tool descriptions explain what is returned narratively ('returns a modeled premium...') but no structured schema is visible in source. LLMs cannot plan downstream operations without knowing response field names and types.
No error handling guidance. Tool descriptions lack recovery hints (e.g., 'If API key is invalid, call whoami() first to verify credentials'). Agents cannot self-correct on failures.
Tool annotations missing. All 8 tools are read-only (no state mutation), but none declare readOnlyHint=true. This prevents agents from optimizing retry logic and understanding safety guarantees.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2026-07-28+ | v2 |
Modeled premium estimate for cross-chain bridge execution failure against a modeled SLA expectation. Returns a modeled premium and conditions — not a live cover, refund, or premium-acceptance offer.
Modeled premium estimate for slashing risk on a liquid-restaking-token (LRT) position given its AVS exposure. Returns a modeled premium and slashing bounds — not a live cover offer.
Modeled premium estimate for MEV-sandwich exposure on a swap. Returns a modeled premium (bps + USD), expected/CVaR loss, and conditions. Point-in-time decision support before routing a trade — not a live cover, insurance, or premium-acceptance offer.
Run a what-if Monte Carlo: model expected premium vs expected refund/loss over a horizon, given assumptions about sandwich frequency, average loss, and deductible. Returns a narrative + distribution.
Confirm the configured API key works and report which plan tier it carries. Returns the owning account email and tier.
Parameter descriptions include example values (e.g., 'e.g. USDC/ETH', 'e.g. uniswap-v3', 'e.g. weETH'). LLMs tend to reuse examples literally rather than adapting to context, causing hallucinated values.
check_swap description is verbose (400+ chars) and mixes multiple concerns (route quality, slippage, MEV exposure, token registry, verdict logic). Could be split into clearer sub-points or a shorter summary with a link to full docs.