FiatDock

Get a free quote

get_quote

Read-onlyIdempotent

Free quote before paying: the exchange rate and exactly how much lands in the bank (or wallet) NET of every provider fee — that net figure is the number to decide on. Executable estimate, not a locked rate. side=SELL (USDC->fiat) or BUY (fiat->USDC).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`side`	No	SELL = USDC to fiat, BUY = fiat to USDC	SELL
`network`	No	USDC network, default base
`fiatAmount`	No	Fiat amount (for BUY)
`cryptoAmount`	No	USDC amount (required for SELL)
`fiatCurrency`	No	e.g. EUR, default EUR

Output Schema

TableJSON Schema

Name	Required	Description
`asOf`	No	ISO timestamp of the quote
`note`	No	Caveats — youReceive is net of provider fees; the x402 session fee is separate
`rate`	Yes	Exchange rate used (fiat per USDC)
`side`	Yes	Quote direction
`source`	No	Where the price came from (the provider's own conversion API)
`network`	No	USDC network the quote assumes
`youSend`	Yes	Amount the sender pays, e.g. '100 USDC'
`youReceive`	Yes	Amount received NET of all provider fees, e.g. '87.78 EUR' — this is the number to decide on
`fiatCurrency`	No	Fiat currency of the quote
`providerFixedFee`	No	Provider-reported fixed fee component
`providerNetworkFee`	No	Provider-reported network delivery fee (0 on Base)

TDQS

A4.4/5.0

Behavior5/5

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

The description adds significant behavioral context beyond the annotations (readOnlyHint, idempotentHint, openWorldHint). It discloses that the quote is an 'executable estimate, not a locked rate' and explicitly states it provides the net amount after fees. This helps an agent understand the dynamic nature of the quote and that it is not a binding offer.

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

Conciseness5/5

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

The description is extremely concise: two sentences and a quick note about 'side'. It front-loads the core value proposition ('free quote before paying: exchange rate and net amount') and immediately addresses the estimate nature. Every sentence adds unique value, with no filler.

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?

Given the presence of an output schema (handling return values) and strong annotations, the description covers the key behavioral aspects: net-of-fees display, estimate disclaimer, and side direction. It does not explain conditional parameter requirements (e.g., cryptoAmount required for SELL), but the schema descriptions compensate. Slightly incomplete for a fully contextual description, but certainly adequate.

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?

The input schema already covers all 5 parameters with descriptions, achieving 100% schema description coverage. The description redundantly explains the 'side' parameter (SELL/BUY) but does not add new information beyond the schema. Baseline score of 3 is appropriate given that the schema carries the burden.

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 clearly states the tool's purpose: providing a free quote with exchange rate and net amount after fees, distinguishing between SELL and BUY directions. It uses specific verbs ('get a free quote', 'executable estimate') and resource ('quote'), which differentiates it from sibling tools like 'create_offramp_session' or 'get_order_status'.

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?

The description implies usage before paying ('free quote before paying') and clarifies it is an estimate ('not a locked rate'). However, it does not explicitly state when not to use this tool or suggest alternative sibling tools for other scenarios, such as creating a session. Still, the context is clear enough for an agent to infer primary usage.

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

All FiatDock tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

Most tools are clearly separated by resource and action, but a few intentional bundles create mild selection overlap: token_report duplicates the data from token_price + token_safety, and address_intel overlaps eth_balance/usdc_balance plus safety. The descriptions explain the trade-offs well, so this is a minor rather than severe issue.

Naming Consistency4/5

Data-query tools follow a solid subject_metric pattern (token_price, usdc_balance, tx_status), while state-changing tools use verb_object (create_onramp_session, call_service). The pattern is readable and mostly consistent, but not a single uniform verb_noun convention throughout, so it falls just short of perfect.

Tool Count4/5

18 tools is above the typical 3-15 well-scoped range, but the server genuinely spans Base chain primitives, token intelligence, fiat ramps, and a marketplace. Each tool has a purpose, and the count is reasonable rather than bloated.

Completeness4/5

Core workflows are covered end-to-end: quote -> create on/off-ramp session -> order status; token price/safety/metadata/report; marketplace search/get/call; chain/tx primitives. Minor gaps exist, such as no order cancellation, no list-all-services endpoint, and no supported-country/method endpoint despite those details living in descriptions.

Get a free quote

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources