Soheil Router

Get a quote

get_quote

Read-only

The best price for a token swap on one network, or a transfer to another network (bridge), and the transaction that makes it, through our contract. Returns toAmount, toAmountMin (enforced on-chain), the fees, approvalAddress (approve it for exactly fromAmount first unless fromToken is the coin) and transactionRequest for the user to sign. Needs an API key.

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": {
      "fromChainId": "<fromChainId>",
      "fromToken": "<fromToken>",
      "toToken": "<toToken>",
      "fromAmount": "<fromAmount>",
      "fromAddress": "<fromAddress>"
    },
    "name": "get_quote"
  }
}

Input Schema

Name	Required	Description
`toToken`	Yes	Token bought
`fromToken`	Yes	Token sold; the coin is 0x0000000000000000000000000000000000000000
`toAddress`	No	Where the tokens go; defaults to fromAddress
`toChainId`	No	Where the recipient receives: fromChainId for a swap (the default), or another of the router's networks to bridge there (toToken an asset the bridge carries, like USDC or ETH; any fromToken is swapped first when needed)
`fromAmount`	Yes	Amount sold, an integer string in the token's smallest unit
`fromAddress`	Yes	The wallet that pays and signs
`fromChainId`	Yes	Network chain id, e.g. 8453 for Base (see get_networks)
`slippageBps`	No	Max price move in basis points, 1 to 5000 (default 50)
`integratorBps`	No	Your own fee in basis points, up to your key's limit

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026

changedInput schema / properties / toChainId / description

Previous value: -"Same as fromChainId for now (same-network swaps); defaults to it"New value: +"Where the recipient receives: fromChainId for a swap (the default), or another of the router's networks to bridge there (toToken an asset the bridge carries, like USDC or ETH; any fromToken is swapped first when needed)"

First observedNov 7, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already mark it read-only and open-world. The description adds that an API key is required, that toAmountMin is enforced on-chain, and that the user must approve approvalAddress for exactly fromAmount unless selling the native coin, which is material workflow context beyond the annotations.

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?

Two sentences, front-loaded with purpose; the second sentence is a dense but useful list of outputs and the approval caveat. There is no filler or repetition, though the return-value list is slightly run-on.

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?

No output schema exists, and the description compensates by naming the key return fields (toAmount, toAmountMin, fees, approvalAddress, transactionRequest) and the approval step. For a 9-parameter quote tool this is largely complete, though quote expiry and refresh behavior are unaddressed.

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 parameters like fromToken, toChainId, slippageBps, and integratorBps are already documented. The description adds little format or constraint detail beyond the schema, except noting the approval amount matches fromAmount and the native-coin exception, so the baseline 3 applies.

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 first sentence names a specific resource (quote) and scope: best price for a token swap or cross-network bridge, plus the transaction. That is enough to distinguish it from get_networks, get_api_info, and get_trade_status without opening the schema.

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?

It clearly frames the use case as obtaining a best-price swap or bridge quote plus the transaction to sign, and notes the API-key prerequisite. It does not explicitly route the agent away from or toward siblings like get_trade_status or get_networks, so it stops short of full when/when-not guidance.

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

All Soheil Router 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.