TRDEFI Liquidity

Swap quote

trdefi_quote

Read-onlyIdempotent

Price a swap against one position, on-chain, at the current block — no custody, nothing signed, nothing moved. Works on any pair the position trades, not only stablecoins. Use this to check liquidity and get the output amount before preparing a swap. If a position answers "Strategy is gated", the maker embedded an access-licence check in the order: the CALLER must hold the 1inch Aqua access token. That check reads tx.origin, so the revert depends on whether a caller was supplied: without one it is 0x89c62b64 ("the caller holds none"), with one it is 0x39c4052c (the tx-origin balance check). Pass from with the address that will actually sign the swap. A caller that holds the maker's credential gets a real price; anyone else gets an accurate "you do not hold it" instead of the least specific answer available. This is a property of the strategy, not a bug — and it is strongly per-network. Measured 2026-10-19: on Ethereum 58 of 60 sampled positions are gated, and across 17 networks the network-balanced split is about 62 percent gated and 17 percent priced. The credential contract itself is only deployed on the 13 Aqua chains, so Arc, Monad, Cronos and HyperEVM have no such gate. The response also decodes the fee from the signed order: fee_decoding is decoded/none/unsupported, maker_fee_percent is the maker commission (for example 0.00025), maker_fee_receiver is its receiver, and fees lists every fee instruction. Quotes are simulated on 17 networks: ethereum, base, arbitrum, optimism, polygon, arc, bnb-chain, gnosis, avalanche, sonic, linea, zksync-era, monad, unichain, hyperevm, cronos and robinhood-chain. This list is the set the quote path actually serves; if a network is not on it, do not promise a quote for it.

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": {
      "hash": "<hash>",
      "amount": "<amount>"
    },
    "name": "trdefi_quote"
  }
}

Input Schema

Name	Required	Description	Default
`from`	No	The address that will sign the swap, simulated as msg.sender. Supply it whenever the caller might hold the maker's access credential: the gate is checked on tx.origin, so with an address the answer is the real one, and without one it is the least specific one.
`hash`	Yes	Strategy hash to quote against.
`chain`	No	Network key. Defaults to "ethereum".
`amount`	Yes	Input amount in token base units, as an integer string. e.g. "1000000" for 1 USDC.
`wallet`	No	The wallet that would trade. When a position is gated, this asks for a Fusion price instead: a 1inch resolver fills the order, so the wallet needs no credential, and the answer is executable rather than indicative. Omit it and a gated position answers an indicative price that no unlicensed wallet can fill.
`direction`	No		aToB

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 6, 2026

addedInput schema / properties / wallet

Added value: +{
+  "description": "The wallet that would trade. When a position is gated, this asks for a Fusion price instead: a 1inch resolver fills the order, so the wallet needs no credential, and the answer is executable rather than indicative. Omit it and a gated position answers an indicative price that no unlicensed wallet can fill.",
+  "pattern": "^0x[a-fA-F0-9]{40}$",
+  "type": "string"
+}

Changed1 schema field changedOct 20, 2026

addedInput schema / properties / from

Added value: +{
+  "description": "The address that will sign the swap, simulated as msg.sender. Supply it whenever the caller might hold the maker's access credential: the gate is checked on tx.origin, so with an address the answer is the real one, and without one it is the least specific one.",
+  "pattern": "^0x[a-fA-F0-9]{40}$",
+  "type": "string"
+}

First observedSep 26, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses the gating behavior, the exact revert selectors (0x89c62b64 vs 0x39c4052c), the tx.origin dependency, per-network gating statistics, and the supported-network list. That is unusually rich behavioral context for a read-only simulation tool.

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 core purpose is front-loaded in the first sentence, but the body sprawls: revert selectors, sampling statistics (58 of 60, 62 percent), and a full 17-network enumeration make it long for a quote tool. Much of it earns its place, but the statistical detail and the "property of the strategy, not a bug" aside could be trimmed.

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 no output schema, the description carries the return-value burden and does so: it documents `fee_decoding`, `maker_fee_percent`, `maker_fee_receiver` and `fees`. Combined with the network list and gating explanation, an agent has everything needed to call and interpret this tool.

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 already 83%, so the baseline is 3, but the description adds real meaning: it explains the `from` vs `wallet` distinction (msg.sender vs Fusion resolver path) and the consequence of omitting each. The `chain` parameter's valid values are enumerated in prose, compensating for the schema's bare "Network key" description.

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?

"Price a swap against one position, on-chain, at the current block" gives a specific verb, resource and scope, and the follow-up clarifies it is a simulation with no custody or signing. It also implicitly separates itself from the Fusion siblings by explaining when a Fusion price is returned instead.

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?

"Use this to check liquidity and get the output amount before preparing a swap" states the intended moment of use, and the `wallet` discussion explains the alternative path (Fusion pricing) and when to take it. It stops short of naming trdefi_fusion_quote explicitly as the sibling to call for executable fills.

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

All TRDEFI Liquidity 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?