SiteCheck Crypto & Finance

SushiSwap route quote for an exact-input swap on one EVM

crypto_sushiswap_route_quotes

Read-only

SushiSwap route quote for an exact-input swap on one EVM chain: amount out, swap price, price impact, gas spent and the tokens in the route. Quote only, no transaction data. The API needs a sender address; if none is given, a fixed placeholder address is sent and nothing is signed or executed. Related tools on this server, for a different need: crypto_1inch_pathfinder_quotes when you need best swap quote for a token pair on an EVM chain, compared. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tokenIn": "<tokenIn>",
      "tokenOut": "<tokenOut>",
      "amountIn": "<amountIn>"
    },
    "name": "crypto_sushiswap_route_quotes"
  }
}

Input Schema

Name	Required	Description
`sender`	No	Optional sender address for the API (quote unaffected)
`chainId`	No	EVM chain id (default 1)
`tokenIn`	Yes	Token to sell, 0x address (use the wrapped token for native ETH)
`amountIn`	Yes	Amount to sell in the token's smallest unit (wei for 18 decimals)
`tokenOut`	Yes	Token to buy, 0x address

Output Schema

Name	Required	Description	Default
`source`	No
`chainId`	No
`tokenIn`	No
`amountIn`	No
`gasSpent`	No
`tokenOut`	No
`amountOut`	No
`checkedAt`	No
`swapPrice`	No
`routeTokens`	No
`priceImpactPct`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses that no transaction data is returned, that a placeholder sender address is substituted so nothing is signed or executed, and that billing is $0.002 USDC per successful call via x402 with failed calls free. Those are exactly the operational facts an agent needs before calling a paid, open-world quote endpoint.

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 first sentence front-loads purpose and return fields, then moves to sender behavior, then alternatives, then price — a sensible priority order with no filler. The alternative-tool sentence is grammatically clumsy ('for a different need ... compared') and costs a little readability.

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?

With an output schema present, the description does not need to explain return values, yet it still names them; it covers the only non-obvious parameter behavior (sender), the payment model, and the sibling alternative. Nothing material for correct invocation is left out.

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%, so the baseline is 3, but the description adds real meaning the schema does not: it explains that the API requires a sender yet the quote is unaffected and a placeholder is used when omitted. It also frames amountIn/tokenIn as an exact-input sell, which clarifies how the required trio combine.

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?

Names a specific verb and resource ('SushiSwap route quote for an exact-input swap on one EVM chain') and enumerates what the quote contains (amount out, swap price, price impact, gas, route tokens). It also explicitly distinguishes itself from the sibling crypto_1inch_pathfinder_quotes, so an agent can pick between them without opening schemas.

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?

States a clear boundary ('Quote only, no transaction data') and points to the concrete alternative for a related need. The exclusion is implied rather than spelled out (execute/swap transactions are not served here), and the sibling comparison phrasing is awkward, but the routing intent is unmistakable.

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

All SiteCheck Crypto & Finance tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?