Which integrations are available for this server?

Provides tools for pre-trade swap checks, risk assessment, and scenario simulation on the Ethereum blockchain, including MEV exposure and token registry verification. Provides tools for pre-trade swap checks and risk assessment on the Robinhood Chain, including MEV exposure and token registry verification.

How do I use @routescore/mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@routescore/mcp check swap on Ethereum: 1 ETH for USDC on Uniswap" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

@routescore/mcp

Official

by routescore

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

@routescore/mcp

The read-only pre-sign evidence layer — a "pre-sign journal" — for onchain agents.

Before an agent (or you) signs a swap onchain, check_swap returns a modeled read of route quality, MEV/execution exposure, and token-registry recognition as a clear / caution / unsupported verdict with its caveats — and persists a hash-verifiable record of exactly what was known before signing, re-verifiable offline. That record is the pre-sign journal. It is read-only: it never signs, executes, routes funds, or custodies assets.

An MCP server (and a keyed REST API) for Claude, Codex, Cursor, and any MCP-capable agent — a thin, stateless wrapper around the Routescore public API, storing no request or response data locally.

check_swap is free. A free API key runs 100 pre-sign checks/day (Pro 1,000/day, Power 10,000/day); the modeled premium-estimate tools, simulate_scenario, and persisted-record retrieval are Power-tier. Generate a key at Account → Developer → API & MCP access (/account) — free to mint on any plan. Keys look like rs_live_… and are shown once.

See how these modeled reads have tracked measured on-chain outcomes on the public calibration surface — Routescore publishes its own accuracy (Brier score, ECE, coverage), re-derivable from a bound source manifest.

Setup

Add the server to your MCP client config and set your key in the env block.

Claude Desktop (claude_desktop_config.json) / Cursor (.cursor/mcp.json):

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

Claude Code (CLI):

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

Optional env:

ROUTESCORE_API_URL — override the API base (default https://www.routescore.io). Useful for local development: http://localhost:3000.

The server checks the key at startup: if ROUTESCORE_API_KEY is missing or does not match the minted key shape (rs_live_ followed by 64 lowercase hex characters), it exits immediately with an actionable error instead of failing on the first tool call. The configured value is never echoed. This is a shape check only — real key verification stays server-side (run the whoami tool).

Related MCP server: defi-yield-scanner-mcp

Tools

Tool	What it does
`quote_mev_cover`	Modeled premium estimate for MEV-sandwich exposure on a swap (modeled premium, expected/CVaR loss).
`quote_bridge_refund`	Modeled premium estimate for cross-chain bridge execution failure vs a modeled SLA expectation.
`quote_lrt_slashing`	Modeled premium estimate for slashing risk on an LRT position given AVS exposure.
`simulate_scenario`	What-if Monte Carlo: modeled expected premium vs refund/loss over a horizon.
`check_swap`	Pre-trade check an agent runs before it signs: modeled route quality, price-impact / slippage band, modeled MEV/execution exposure where observable, and a token registry read (recognized vs unverified), as a `clear / caution / unsupported` verdict. Supports Ethereum (1) and Robinhood Chain (4663). Recognition is not safety, sellability, rights, redemption, liquidity, or investment-quality verification. Decision support, not execution. Every keyed call also attempts to persist a hash-verifiable evidence record and returns its `record_id`, `evidence_bundle_id`, and `record_output_hash` — null, with a `record_persistence_failed` caveat, if the record store is unavailable.
`get_preflight_record`	Fetch one persisted preflight evidence record by `record_id` (owner-scoped to the configured key's account). The record embeds the original check response verbatim plus a canonical-JSON SHA-256 integrity hash so the evidence can be re-verified offline. Read-only evidence: record creation rejects known execution-material keys (calldata, transaction payloads, signing material) and drops identity-shaped labels from the actor context.
`get_detector_manifest`	Latest public MEV-detector run manifest (version hash + universe).
`whoami`	Confirm the key works and report its plan tier.

All quote_* tool results are modeled, point-in-time premium estimates — decision support only, not a live cover, insurance, refund, or premium-acceptance offer. Routescore does not underwrite risk.

Output contract

Routescore MCP is decision support, not execution infrastructure. check_swap, quote, and scenario tool results preserve the same trust envelope as the REST API, and the wrapper marks output as degraded if the upstream API ever omits required trust fields.

check_swap answers verdict: unsupported as an HTTP 422 with a full evaluated body — an answer, not an error. The wrapper relays those evaluated 422 bodies as normal structured tool results (gap-state fields, caveats, and record linkage included) so agents receive "not evaluated" as first-class evidence; true errors (400/401/403/404/429/5xx and non-evaluated 422 error envelopes) still surface as tool errors.

Downstream agents and dashboards should render the trust-envelope fields by default (abbreviated example):

{
  "score_state": "partial",
  "source_freshness": {
    "state": "partial",
    "checked_at": "2026-06-21T00:00:00.000Z",
    "sources": [
      { "name": "routescore_backend", "freshness_state": "fresh" },
      { "name": "bridge_risk_labels", "freshness_state": "unknown" }
    ]
  },
  "methodology_version": "routescore.public_api.v1",
  "confidence_band": { "low": null, "high": null, "unit": "bps" },
  "caveats": [
    "Modeled, point-in-time decision support. Not an execution guarantee.",
    "Unsupported or stale inputs widen uncertainty instead of hiding risk."
  ],
  "commercial_disclosure": {
    "paid_placement": false,
    "score_influenced_by_partner": false
  }
}

Local development

npm install
npm run build
ROUTESCORE_API_KEY=rs_live_... ROUTESCORE_API_URL=http://localhost:3000 node dist/index.js

Then point MCP Inspector at the command, or wire it into a client config as above.

Public Reddit research utility

The retail-research workflow includes a standard-library parser for a saved, publicly rendered old Reddit thread. It extracts public handles, comment counts, IDs, and permalinks without logging in or attempting to recover deleted authors:

python3 scripts/scrape_reddit_public_handles.py /path/to/thread.html \
  --csv work/reddit-public-handles.csv \
  --json work/reddit-public-handles.json

The input must be HTML already obtained from a public old.reddit.com thread. The parser does not fetch pages or bypass Reddit access controls.

Notes

Scenario and quote outputs are modeled decision-support, not investment advice.
MCP does not custody assets, execute transactions, route funds, or guarantee outcomes.
Rate limits apply per key; responses carry X-RateLimit-* headers.

Available Tools

8 tools

check_swapAInspect

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.

ParametersJSON Schema

Name	Required	Description
`route`	No	Route id to score, e.g. 'uniswap-v3-rho'. Omit to score the chain's default public route.
`chain_id`	No	Chain ID. 1 = Ethereum (default), 4663 = Robinhood Chain.
`token_in`	No	Token being sold (address or symbol).
`token_out`	No	Token being received (address or symbol) — checked against Routescore's recognized-token registry (recognized vs unverified). RHC tokenized stock/ETF address-level recognition uses the Routescore registry contract address; symbol-only input is downgraded to unverified. Symbol-only recognition is not contract verification. Recognition is not a safety, sellability, rights, redemption, liquidity, or investment-quality verdict; unverified means Routescore has not confirmed the token.
`notional_usd`	Yes	Trade size in USD.
`slippage_allowance_bps`	No	Slippage allowance in bps. Default 50.

TDQS

A4.2/5.0

Behavior5/5

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

With no annotations, the description fully carries the transparency burden. It clearly states the tool is read-only, does not route funds, sign, or promise outcomes, and explains caveats about token recognition not implying safety. This exceeds minimal disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is verbose (over 150 words) and includes repetitive caveats. While front-loaded with a strong usage instruction, it could be more concise without losing critical information.

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?

Given the tool's complexity (6 params, no output schema, no annotations), the description provides a solid overview of what is returned (grade, price impact, MEV exposure, token registry, verdict) and explains caveats. However, it lacks specific output structure details that would aid an agent in parsing results.

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 baseline is 3. The description adds context about parameters (e.g., notional, chain, route) but does not detail each beyond what the schema provides. No significant additional meaning beyond schema.

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

Purpose5/5

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

Description clearly states the tool's purpose: read-only pre-sign evidence check for onchain swaps, returning grade, price impact, MEV exposure, token registry, and a verdict. It distinguishes from siblings by focusing specifically on swap checks, unlike other tools like get_detector_manifest or quote_bridge_refund.

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?

Explicitly instructs 'CALL THIS BEFORE SIGNING AN ONCHAIN SWAP' and clarifies it does not execute or sign. However, it does not mention alternatives among siblings, such as when to use get_preflight_record instead, leaving some ambiguity.

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

get_detector_manifestAInspect

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It declares the operation is a 'fetch' (read-only), and specifies 'public' and what is returned. It does not mention auth, rate limits, or error states, but given the simplicity, it is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words, with the key action and purpose in the first sentence.

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

Completeness5/5

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

Given no parameters, no output schema, and a simple fetch operation, the description fully covers what the tool does and why to use it.

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

Parameters4/5

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

No parameters exist in the schema, so description cannot add parameter meaning. The baseline for zero parameters is 4, and the description does not introduce confusion.

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

Purpose5/5

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

The description uses specific verbs 'Fetch' and 'verify', identifies the resource (MEV-detector run manifest) and its content (version hash, pool/token universe). It clearly distinguishes from sibling tools which focus on swaps, quotes, simulations, etc.

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?

Explicitly states 'Use to verify what the detector covers', providing a clear use case. No explicit exclusions or alternatives mentioned, but the context is sufficient for a simple tool.

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

get_preflight_recordAInspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`record_id`	Yes	The record id returned by check_swap (its record_id field).

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses the read-only nature, rejection of execution-material keys, and inclusion of an integrity hash. However, it does not mention error cases or performance implications.

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 description is a single paragraph with information front-loaded about purpose and usage. While detailed, every sentence adds value and the length is appropriate for the complexity.

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?

Given one parameter and no output schema, the description explains the tool's workflow position, parameter, return contents, and security restrictions. It is comprehensive but could explicitly describe the output structure.

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

Parameters4/5

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

Schema coverage is 100% and the parameter description in the schema specifies it is the record_id returned by check_swap. The description reinforces this context, adding value beyond the schema.

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

Purpose5/5

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

The description clearly states the tool retrieves a durable evidence record from a prior check_swap call, specifying it is the 'record' leg of a four-step process. It distinguishes from siblings by focusing on fetching an existing record rather than creating or simulating.

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 description specifies to use this tool after a check_swap call by providing the record_id. It notes owner-scoping and read-only access, but does not explicitly state when not to use it or suggest alternatives.

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

quote_bridge_refundBInspect

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.

ParametersJSON Schema

Name	Required	Description
`bridge`	No	Bridge name, e.g. 'across'.
`sla_seconds`	No	Expected delivery SLA in seconds. Default 60.
`notional_usd`	Yes	Amount bridged in USD.
`dest_chain_id`	No	Destination chain ID. Default 8453 (Base).
`source_chain_id`	No	Source chain ID. Default 1.
`bridge_risk_score`	No	Bridge risk score 0–1. Default 0.05.

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description bears the burden. It discloses that the output is a 'modeled' estimate, not a binding offer, which is important. However, it does not address potential side effects, error conditions, or whether the tool is read-only, leaving some ambiguity.

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 description is a single sentence with a clarifying follow-up, making it concise and front-loaded. It avoids verbosity, though the technical jargon may slightly hinder immediate clarity.

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

Completeness3/5

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

Given no output schema and sibling tools in the same domain, the description provides basic context but lacks details on return format, conditions, and parameter interactions. It is minimally adequate.

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?

Input schema covers 100% of parameters with descriptions, so baseline is 3. The description adds contextual meaning (cross-chain bridge failure against SLA) but does not enhance parameter semantics beyond the schema.

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 clearly states the tool provides a 'modeled premium estimate' for 'cross-chain bridge execution failure against a modeled SLA expectation', distinguishing it from live cover or refund offers. The verb 'quote' is implicit in the name, and the resource is well-defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions this is not a live offer, which sets expectations but does not explicitly state when to use this tool over siblings like 'quote_lrt_slashing' or 'quote_mev_cover'. Lack of explicit when-to-use guidance drops the score.

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

quote_lrt_slashingBInspect

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.

ParametersJSON Schema

Name	Required	Description
`lrt_token`	No	LRT token, e.g. 'weETH'.
`covered_eth_amount`	Yes	ETH amount used as the modeled position size.
`cover_duration_weeks`	No	Modeled cover duration in weeks. Default 12.
`correlation_max_overlap`	No	Max correlation overlap 0–1. Default 0.5.
`underlying_avs_exposure`	No	AVS exposure weights, e.g. { "EigenDA": 1.0 }.

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden. It discloses the output type (modeled premium and slashing bounds) but does not mention side effects, idempotency, authorization needs, or that it is a read-only operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with purpose, and every sentence adds value. No fluff.

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

Completeness2/5

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

The description lacks details about the return structure, how to interpret results, and any prerequisites for the nested object parameter. For a tool with 5 parameters and no output schema, more context is needed.

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 coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond what the schema provides.

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

Purpose5/5

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

The description clearly states the tool provides a modeled premium estimate for slashing risk on an LRT position. It uses a specific verb ('quote') and resource ('LRT slashing'), and distinguishes from siblings like 'quote_mev_cover' and 'quote_bridge_refund' by focusing on slashing risk.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for obtaining a modeled estimate, but does not explicitly state when to use or when not to use. Sibling tools exist but no guidance on alternatives is provided.

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

quote_mev_coverAInspect

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.

ParametersJSON Schema

Name	Required	Description
`route`	No	Execution route, e.g. 'uniswap-v3'.
`chain_id`	No	Chain ID (1 = Ethereum). Default 1.
`asset_pair`	No	Asset pair, e.g. 'USDC/ETH'. Default USDC/ETH.
`notional_usd`	Yes	Trade size in USD.
`refund_threshold_bps`	No	Modeled refund threshold in bps. Default 50.
`slippage_allowance_bps`	No	Slippage allowance in bps. Default 50.
`historical_sandwich_freq`	No	Historical sandwich frequency as a 0–1 fraction. Default 0.012.

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It clearly conveys the tool is a modeled estimate (non-binding, read-only) and not a live commitment. It mentions return outputs but does not disclose rate limits, authentication needs, or side effects. Since it's a quote tool with no destructive potential, the description is reasonably transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences. The first states what the tool does and what it returns. The second clarifies its non-binding nature. Every word is essential; no fluff or repetition.

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?

Given no output schema, the description adequately explains return values (premium, loss, conditions). It contextualizes the tool as pre-trade decision support and clarifies it is not a live offer. For a quote tool with 7 parameters, it is mostly complete, though it could elaborate on how parameters influence the model.

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 coverage is 100% (all 7 parameters have descriptions). The tool description does not add semantic value beyond the schema; it summarizes the output but not the parameters. With full schema coverage, a baseline of 3 is appropriate as the description does not need to repeat parameter details.

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

Purpose5/5

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

The description clearly states it provides a modeled premium estimate for MEV-sandwich exposure on a swap, listing specific outputs (premium in bps + USD, expected/CVaR loss, conditions). It distinguishes itself from live cover or insurance, and the sibling tools (e.g., check_swap, quote_bridge_refund) confirm it occupies a distinct niche as a point-in-time decision support tool.

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 description specifies it is 'point-in-time decision support before routing a trade' and explicitly states it is 'not a live cover, insurance, or premium-acceptance offer.' This gives clear context for when to use or not use the tool, though it does not directly contrast with related sibling tools like check_swap or quote_bridge_refund.

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

simulate_scenarioAInspect

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.

ParametersJSON Schema

Name	Required	Description
`avg_loss_bps`	No	Average sandwich loss in bps. Default 40.
`horizon_days`	No	Horizon in days (≈ swaps). Default 30.
`notional_usd`	Yes	Per-swap notional in USD.
`deductible_bps`	No	Deductible in bps. Default 100.
`sandwich_freq_pct`	No	Sandwich frequency as a percentage 0–100. Default 1.2.

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description must fully disclose behavior. It states the simulation returns 'a narrative + distribution' but does not clarify if the tool is read-only, whether it has side effects, or any computational or rate-limit considerations. Basic transparency is present but incomplete for a Monte Carlo tool that could be resource-intensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core action ('Run a what-if Monte Carlo') and outcome ('Returns a narrative + distribution'). Every phrase adds value, with no repetition or fluff. Highly efficient.

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 simulation tool with no output schema, the description vaguely states 'narrative + distribution' but does not specify the shape or format of the output. However, given the tool's purpose and the presence of well-documented parameters, the description is nearly complete. A more detailed output specification would improve it.

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 coverage is 100%, so each parameter already has a description. The description adds context by grouping parameters as 'assumptions about sandwich frequency, average loss, and deductible,' but does not provide additional syntax or format details beyond the schema defaults. Baseline score of 3 is appropriate.

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

Purpose5/5

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

The description uses specific verbs ('Run a what-if Monte Carlo') and clearly states the resource ('model expected premium vs expected refund/loss'). It distinguishes this simulation tool from sibling tools like 'quote_mev_cover' or 'check_swap' by explicitly naming the analysis type (Monte Carlo) and the inputs (sandwich frequency, average loss, deductible).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use (for 'what-if' modeling) but provides no explicit guidance on when not to use or alternatives. It does not mention prerequisites or contrast with sibling tools, leaving the agent to infer usage context without clear boundaries.

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

whoamiAInspect

Confirm the configured API key works and report which plan tier it carries. Returns the owning account email and tier.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior5/5

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

No annotations provided, but the description fully discloses the tool's read-only, non-destructive behavior and return values. This is sufficient transparency for an auth check tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no extraneous words. Every sentence adds value: first states action, second states return values.

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 tool with no parameters and no output schema, the description covers what it does and what it returns. However, it omits error handling or edge cases (e.g., invalid API key behavior), which could be added for completeness.

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?

With no parameters and schema coverage at 100%, the description adds no parameter semantics, but none are needed. Baseline score of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool's purpose: confirming API key validity and reporting plan tier, plus what it returns (email and tier). It is distinct from sibling tools which deal with swaps, detectors, etc.

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 description implicitly guides when to use (to check API key and plan tier) but does not explicitly mention when not to use or suggest alternatives. However, the context is clear given the tool's simplicity.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv0.3.3Jul 15, 2026
- First observedcheck_swap
- First observedget_detector_manifest
- First observedget_preflight_record
- First observedquote_bridge_refund
- First observedquote_lrt_slashing
- First observedquote_mev_cover
- First observedsimulate_scenario
- First observedwhoami

Deploy Server

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

TDQS

A4/5.0

Scored 2026-07-15 00:30 across 8 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: pre-swap evidence check, detector manifest, record retrieval, quotes for different risk types, simulation, and authentication. No two tools overlap in functionality.

Naming Consistency4/5

Most tools follow a verb_noun pattern (e.g., check_swap, get_detector_manifest, quote_mev_cover). However, 'whoami' deviates with no verb-object structure, causing minor inconsistency.

Tool Count5/5

8 tools is well-scoped for a risk assessment server covering pre-swap checks, quotes, simulation, and record retrieval. Not too few or too many.

Completeness4/5

The tool set covers core workflows: pre-swap evidence, quotes for various risks, simulation, and record retrieval. Minor gap: no tool to list all preflight records or manage account settings, but overall sufficient for its domain.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Backtest360 A
com.backtest360
MCP server exposing the Backtest360 engine API as tools for AI agents.
Finance Research & Data
202
mcp AOAuth
io.scorecard
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
RAG Systems Monitoring Testing & QA Tools
3
secureflows-mcp A
io.github.michal-lefler
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Code Analysis Developer Tools Security
181
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21

Related MCP Servers

agentforge
Agent Orchestration AI & Machine Learning
doggychip
F
license
A
quality
F
maintenance
MCP server that exposes 300+ AI agents as tools via a single API key. Supports listing agents, invoking any agent with chat-completion style messages, checking agent health, and retrieving platform statistics.
Updated 5 months ago (2026-04-21 17:13 UTC)
5
4
-
defi-yield-scanner-mcp
Blockchain Cryptocurrency Finance
34t34f3
A
license
A
quality
D
maintenance
Real-time DeFi analytics MCP server for AI agents. Provides token risk analysis, yield scanning, and wallet exposure checking across Base, Ethereum, and Arbitrum.
Updated 6 months ago (2026-04-11 16:49 UTC)
3
7 npm
1
MIT
CodeRifts API Governanceofficial
Agent Orchestration CI/CD & DevOps Security
coderifts
A
license
Not graded
quality
B
maintenance
Signed, offline-verifiable authorization for API-contract changes. Before a contract change (OpenAPI, GraphQL, Protobuf, AsyncAPI, MCP manifests) merges or deploys, the agent calls preflight_change_set; the decision is deterministic, signed, and verifiable without calling CodeRifts. Three tools: preflight_change_set, verify_receipt, get_decision_details. Only a granted change can proceed.
Updated 2 days ago (2026-09-26 20:36 UTC)
4 npm
MIT
orbit-apiofficial
Blockchain Web3 & Decentralized Tech
Orbit-bridge
F
license
Not graded
quality
F
maintenance
MCP server for cross-chain bridging, enabling AI agents to find routes, estimate costs, check risks, execute transfers, and track status across blockchains.
Updated 3 months ago (2026-06-22 12:35 UTC)
-

@routescore/mcp

Setup

Tools

Output contract

Local development

Public Reddit research utility

Notes

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

CodeRifts API Governanceofficial

orbit-apiofficial