Wire the @routescore/mcp server into OpenAI Codex so it can run a pre-sign evidence check before it ever proposes signing an onchain swap. Codex loads MCP servers the same way Claude does, so one block of config gives it the same tools: one check_swap 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 Codex 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)

Read-only, non-custodial

The tools return modeled, point-in-time decision support. Nothing here holds a key, moves funds, or promises an outcome. The MCP server needs an API key — generate one at Account → Developer → API & MCP access.

1. Add the server to your Codex config

Codex reads MCP servers from ~/.codex/config.toml. Add a routescore entry — @routescore/mcp is a thin, stateless wrapper around the keyed REST API (it does not persist your request or response data locally), and npx -y fetches and runs it:

[mcp_servers.routescore]
command = "npx"
args = ["-y", "@routescore/mcp@latest"]
env = { ROUTESCORE_API_KEY = "rs_live_your_key_here" }

The @latest tag follows npm's current published release. For reproducible deployments, run npm view @routescore/mcp version and pin that returned version in your managed config; avoid copying a dated version from this evergreen guide.

Some Codex versions also expose codex mcp add; the config.toml block above is the portable path that works across versions.

2. Ask Codex to preflight before it signs

Once the server is loaded, Codex sees the check_swap and get_preflight_record tools. Put the discipline in your prompt (or your project instructions):

Before you propose signing any onchain swap, call check_swap first and show me the verdict, the modeled route quality, and every caveat verbatim. If the verdict is caution or unsupported, stop and tell me why before doing anything else.

Codex will call the tool, and the response carries a record_id — the pre-sign evidence is persisted as an owner-scoped, hash-verifiable record you can pull later with get_preflight_record and re-verify offline. That's the pre-sign journal: a record of exactly what the agent knew before it signed.

3. What you get back

check_swap returns a structured, modeled read for the intent you pass (chain, token pair, size): a clear | caution | unsupported verdict, a modeled route-quality read, a modeled slippage estimate, a modeled MEV/execution-exposure read where observable, token-registry recognition, the methodology version, and the caveats. It is decision support, not an execution guarantee — Codex should relay the caveats, not paper over them.

See how well the modeled reads have tracked measured outcomes on the public calibration surface, and the full detector methodology in the methodology page.