Integrate with Claude (MCP)

Wire the @routescore/mcp server into Claude so it can run a pre-sign evidence check before it ever asks you to sign an onchain swap. One call returns a modeled route-quality read, a modeled slippage estimate, a modeled MEV/execution-exposure read where observable, a token registry recognition read, and a clear | caution | unsupported verdict — with the caveats Claude should relay to you verbatim.

Routescore is one composable element of an agentic stack — the evidence/attestation element alongside your planner, executor, and wallet. It is read-only: it never signs, executes, routes funds, custodies assets, or gives advice.

plan → preflight (Routescore) → execute (venue/agent) → record (Routescore)

1. Add the server to your Claude config

The published @routescore/mcp package is a thin, stateless wrapper around the keyed REST API — the server does not persist your request or response data locally. npx -y @routescore/mcp@latest fetches and runs the current published release. Use @latest for evergreen installs; pin the version returned by npm view @routescore/mcp version only when your deployment policy requires a reproducible lock.

Claude Desktop — edit claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json; Windows: %APPDATA%\Claude\claude_desktop_config.json):

{
  "mcpServers": {
    "routescore": {
      "command": "npx",
      "args": ["-y", "@routescore/mcp@latest"],
      "env": {
        "ROUTESCORE_API_KEY": "rs_live_your_key_here"
      }
    }
  }
}

Claude Code (CLI) — one command:

claude mcp add routescore --env ROUTESCORE_API_KEY=rs_live_... -- npx -y @routescore/mcp@latest

Restart the client. The server checks the key shape at startup and exits with an actionable error if ROUTESCORE_API_KEY is missing or malformed — so a mistyped key fails fast rather than on the first tool call. A well-formed but invalid or revoked key is only caught server-side; run whoami to confirm it actually works.

2. Confirm the tools are live

Ask Claude to run whoami first — it confirms the key works and reports your plan tier. You should see the Routescore tools appear, including check_swap, get_preflight_record, the quote_* estimators, simulate_scenario, and get_detector_manifest. The full tool table is in the API & MCP guide.

3. Ask Claude to check a swap before you sign

Prompt Claude naturally — it can select check_swap for you (require or verify the tool call yourself when your workflow policy demands a preflight):

Before I sign this, check a $10,000 USDG → tokenized AAPL swap on Robinhood Chain (chain 4663) on the uniswap-v3-rho route. Show me the verdict and the caveats.

check_swap composes, in one call: a clear | caution | unsupported verdict with machine-readable reasons[], a modeled route-quality grade + modeled slippage estimate (modeledSlippageBps), modeled MEV/execution exposure where observable, a token registry recognition read (recognized vs unverified), and the full trust envelope. Abbreviated response shape:

{
  "verdict": "caution",
  "chain": { "chainId": 4663, "name": "Robinhood Chain", "supportLevel": "modeled" },
  "route": { "grade": "A", "qualityScore": 97, "modeledSlippageBps": 25.5, "orderFlow": "sequencer_ordered" },
  "token_safety": { "state": "recognized", "recognized": true, "flags": ["tokenized_asset_registry_only"] },
  "reasons": ["sequencer_ordering_uncalibrated"],
  "score_state": "partial",
  "methodology_version": "routescore.public_api.v1",
  "caveats": [
    "Pre-trade decision support only. Routescore does not execute trades, route funds, or promise an outcome.",
    "Route and execution-risk values are modeled, point-in-time. Token-safety is registry recognition vs unverified status, not a live honeypot, can-sell, rights, redemption, or liquidity audit."
  ]
}

recognized means the token matches Routescore's registry entry — it is not a safety, sellability, liquidity, rights, redemption, or investment-quality verification. An unknown token reads unverified and downgrades the verdict to caution. A valid-but-unsupported request (e.g. an unsupported chain) returns an evaluated unsupported verdict as HTTP 422 with a full body, relayed as a structured tool result — never a plausible-but-wrong number. Malformed input (non-positive notional_usd, a non-integer chain_id, out-of-range slippage) is rejected earlier with HTTP 400 before evaluation.

Every keyed check_swap call also attempts to persist an owner-scoped, hash-verifiable evidence record and returns its record_id (null, with a record_persistence_failed caveat, if the record store is unavailable). Fetch it later with get_preflight_record and re-verify the hash offline.

4. Teach Claude to relay it honestly

The verdict, reasons[], and caveats[] are written to reach your end user verbatim — not paraphrased, softened, or dropped. clear is never a recommendation; it reports the absence of caution-level findings within the stated coverage and score_state. To bind Claude to that discipline automatically, install the two agent skills for Routescore preflight.

Where the proof lives

A verdict is only as good as the model behind it. Routescore publishes its methodology and its calibration state so you can weigh every number:

• /calibration — how modeled figures reconcile against realized outcomes, per source. Where a cohort is too small to be meaningful, it is stated as honest-but-empty rather than dressed up.
• /methodology — how the scores are computed.
• /limitations — what Routescore does not know or do.