Skip to main content
Glama

Ekubo Protocol

Get swap or bridge quotes with execution plans

get_quotes_with_plans
Read-only

A quote, execution plan, simulation or wallet approval is not permission to trade. Robinhood Stock Tokens are tokenised debt securities subject to issuer restrictions and applicable law. Before requesting signatures or submitting approvals or trades, establish the user's relevant jurisdiction and eligibility, including location, residence or entity incorporation, US-person status under Regulation S, any person for whose account or benefit the transaction is made, and issuer Prohibited Investor restrictions. Never infer these facts from an agent or server IP. If required facts or asset-policy coverage are unknown, do not proceed. Only the user or an authorized representative of the actual investor may provide an explicit factual attestation; an agent must not attest on their behalf. A known prohibited fact cannot be overridden by attestation. An attestation is not a license, legal exemption or substitute for required screening. Keep the attestation client-side; do not send it to the quote API or MCP server. No blanket disposal exemption applies. Quote EVM swaps: Ekubo/0x same-chain; Across/LayerZero/LI.FI cross-chain. For plans, supply sender and exactly one protection: whole slippage_bps or exact-input max_output_loss in output base units. Omit all three for indicative quotes. Pass the chosen execution.execution_plan_reference unchanged to wallet simulation; show that result and send the same simulation for owner authorization. Re-quote only after revert, expiry or changed request; never retry reverted bytes or widen protection. For all/max swaps use the wallet's exact balance. Compare amount_out and native_fee (LayerZero charges it separately). Track LayerZero/LI.FI delivery with get_value_transfer_status. unavailable_sources reports provider failures; execution_unavailable reports plan failures.

Input Schema

NameRequiredDescriptionDefault
amountYesBase units (positive decimal integer)
senderNoTransaction sender; pass with exactly one of slippage_bps or max_output_loss for plans (address)
chain_idYesEVM chain ID
token_inYesRaw EVM address or CAIP-10 eip155:<chain_id>:<address>; all-zeroes denotes the native token
recipientNoDefaults to sender (address)
token_outYesRaw EVM address or CAIP-10 eip155:<chain_id>:<address>; all-zeroes denotes the native token
quote_typeYes
slippage_bpsNoWhole-bps calldata bound: 0.1% = 10. With sender supply this OR max_output_loss. Honor user preference; size near gas value / notional * 10,000. For positive sub-bps budgets use max_output_loss, not 0 or 1 bps. No generic 50 bps default. After slippage failure re-quote, never widen or retry reverted bytes.
max_output_lossNoExact-input loss budget from quoted output, output-token base units as a decimal integer string; requires sender, omit slippage_bps. Ekubo: exact subtraction. 0x: two quotes, floor budget to whole ppm, verify final minBuyAmount; positive budgets below 1 ppm fail, never become zero. Others unsupported. Convert gas value to output base units rounding down; never widen to 1 bps.
include_raw_quotesNoEcho raw provider responses; only to diagnose a provider
destination_chain_idNoDestination chain; defaults to chain_id for a same-chain swap
swap_deadline_minutesNoEkubo router route deadline; default 30

Output Schema

NameRequiredDescriptionDefault
quotesNo
jurisdictionNojurisdiction metadata (ekubo-token-jurisdictions-v2): coverage, execution_hold, restricted_jurisdictions, per-asset classification

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true, and the description adds substantial behavior beyond that: the safe workflow (quote → unchanged execution_plan_reference → wallet simulation → owner authorization), the retry prohibition ('never retry reverted bytes or widen protection'), and the distinction between unavailable_sources (provider failures) and execution_unavailable (plan failures). The attestation must stay client-side and not be sent to the API, which is a valuable non-obvious constraint. The remainder is policy prose rather than tool behavior, which keeps it from a 5.

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

Conciseness2/5

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

A dense single block of roughly 250 words that front-loads legal disclaimers ('A quote, execution plan, simulation or wallet approval is not permission to trade') ahead of any operational content. The middle section on jurisdiction, Regulation S and attestation is long and could be compressed, and the actually usable quoting instructions are stranded near the end with no structure or separation.

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 12-parameter tool with an output schema, the definition covers the essential workflow, retry discipline, failure-field meanings, and cross-parameter constraints, so an agent can invoke it correctly. Gaps remain: it never defines the exact_input vs exact_output enum choice, and recipient/destination_chain_id behavior is left entirely to the schema.

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?

With 92% schema coverage the baseline is 3, but the description genuinely adds cross-parameter semantics the schema cannot express: that slippage_bps and max_output_loss are mutually exclusive and both require sender, that they must all be omitted for indicative quotes, that max_output_loss is denominated in output-token base units, and that all/max swaps must use the wallet's exact balance. It also explains that execution.execution_plan_reference must be passed unchanged downstream.

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

Purpose3/5

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

The tool's function is inferable from buried fragments ('Quote EVM swaps: Ekubo/0x same-chain; Across/LayerZero/LI.FI cross-chain', 'Omit all three for indicative quotes'), but the description opens with a compliance disclaimer rather than a statement of what the tool returns. It never says plainly 'returns a quote plus an optional execution plan,' and it does not distinguish itself from siblings such as quote_uniswap_liquidity or the prepare_* tools.

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

Usage Guidelines5/5

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

Explicit decision rules are supplied: omit sender/slippage_bps/max_output_loss for indicative quotes, supply sender plus exactly one protection for plans, and re-quote only after revert, expiry or a changed request. It also names the follow-on sibling ('Track LayerZero/LI.FI delivery with get_value_transfer_status') and states a hard when-not: 'If required facts or asset-policy coverage are unknown, do not proceed.'

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.