Straelo Relay

DeFi Route Decision

defi_route_decision

Read-only

Compare read-only Base swap quotes obtained from 1inch and KyberSwap, evaluating output, minimum output, fees/gas, price impact, consensus, and divergence to return a deterministic economic route decision (EXECUTE_BEST, WAIT, or INSUFFICIENT_DATA). The product consults external providers during the request; quotes reflect the market state observed at that moment and identical calls can produce different results. Provider unavailability or failure can yield a partial result or insufficient data. The product does not execute, submit, sign, or authorize a swap or transaction. USE WHEN: an agent needs to compare available swap routes on Base and determine whether to execute the best route, wait, or treat the available market data as insufficient. DO NOT USE WHEN: the agent needs to execute or submit a swap, sign a transaction, or perform a transaction-safety authorization.

Input Schema

Name	Required	Description
`chain`	Yes	Base Mainnet only in this quote-only MVP.
`token_in`	Yes	Input Base asset symbol.
`amount_in`	Yes	Positive decimal input amount, converted exactly to raw token units.
`token_out`	Yes	Output Base asset symbol; must differ from token_in.
`slippage_bps`	Yes	Slippage tolerance in basis points; it is not treated as a cost.
`baseline_provider`	No	Optional provider used only for a direct economic comparison.

Output Schema

Name	Required	Description
`usage`	Yes	Per-provider call success, latency, and configured cost-estimate availability.
`quotes`	Yes	Normalized provider quote evidence in raw token units.
`status`	Yes	Outcome of the quote comparison: COMPARISON_AVAILABLE when at least two valid quotes exist, PARTIAL when some but not all providers succeeded, UPSTREAM_UNAVAILABLE when no provider returned a valid quote.
`partial`	Yes	True when one or more providers did not yield a valid quote.
`decision`	Yes	Deterministic economic decision: which swap quote the agent should choose right now. Not a safety authorization and does not execute a swap.
`consensus`	Yes	Comparable-output median and comparison basis when two provider quotes are valid.
`economics`	Yes	Known or unknown estimated provider COGS; unknown is never represented as zero.
`confidence`	Yes	Deterministic quote-comparison confidence; two providers never produce HIGH in this MVP.
`observed_at`	Yes	UTC timestamp when the latest provider quote was observed during this request.
`best_provider`	Yes	Best comparable provider only when at least two valid quotes are available.
`decision_reason`	Yes	Human-readable deterministic reason for the decision.
`decision_signals`	Yes	Objective signals used for the decision.
`evidence_quality`	Yes	Per-provider reported, calculated, estimated, or unavailable field quality.
`provider_failures`	Yes	Providers that failed to return a valid quote, with provider name and failure category.
`economic_advantage`	Yes	Best quote versus declared baseline or next available quote; never ROI.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 2, 2026

addedOutput schema / properties / observed_at / description

Added value: +"UTC timestamp when the latest provider quote was observed during this request."

addedOutput schema / properties / provider_failures / description

Added value: +"Providers that failed to return a valid quote, with provider name and failure category."

addedOutput schema / properties / status / description

Added value: +"Outcome of the quote comparison: COMPARISON_AVAILABLE when at least two valid quotes exist, PARTIAL when some but not all providers succeeded, UPSTREAM_UNAVAILABLE when no provider returned a valid quote."

AddedNov 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already flag readOnlyHint=true and openWorldHint=true, but the description adds non-obvious traits: it consults external providers live, identical calls can return different results (consistent with idempotentHint=false), and provider failure can yield partial or insufficient-data results. It also explicitly disclaims any execution/signing authority, closing the main safety question.

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 core behavior and its external/non-deterministic nature are front-loaded, and the USE/DO NOT USE structure is easy to scan. The first sentence is dense with evaluative dimensions that could be trimmed slightly, but no sentence is filler.

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, full schema coverage, and rich annotations, the description supplies exactly the missing pieces: live-provider behavior, result variability, partial-failure outcomes, and absence of execution capability. Nothing an agent needs to call it correctly is missing.

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 each parameter is already documented, including the optional baseline_provider caveat in the schema itself. The description references the evaluated dimensions (output, fees/gas, price impact, divergence) but adds no per-parameter syntax or format detail beyond the schema, so 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 description names a specific verb and resource ('Compare read-only Base swap quotes obtained from 1inch and KyberSwap') and states the concrete output taxonomy (EXECUTE_BEST, WAIT, INSUFFICIENT_DATA). It also distinguishes itself from the execution sibling ('does not execute, submit, sign, or authorize a swap').

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 USE WHEN and DO NOT USE WHEN sections define the exact condition for selection and name the alternative scenario (executing/submitting/signing a swap). The routing decision is unambiguous without opening the schema.

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

All Straelo Relay tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?