What can you do with this server?

One line: This is FiatDock's non-custodial USDC↔bank ramp surface — four tools (two free, two $0.01 via x402) that quote a rate and then hand the human owner a one-time checkout URL to complete a cash-in or cash-out, plus order tracking. * get_quote (free, read-only): indicative exchange rate, fully itemised fees, and the exact amount received for SELL (USDC→fiat) or BUY (fiat→USDC), defaulting to EUR on Base. * create_offramp_session ($0.01 USDC via x402): cashes the agent's USDC out to the owner's own bank account; returns a single-use checkoutUrl for the human plus a partnerOrderId. * create_onramp_session ($0.01 USDC via x402): turns the owner's fiat into USDC delivered to a specified (locked) agent wallet address; same checkout + order-id pattern. * get_order_status (free): polls an order by partnerOrderId through SESSION_CREATED → PROCESSING → COMPLETED | FAILED | CANCELLED | EXPIRED. * Non-custodial handoff: FiatDock never touches funds — conversion, KYC and custody sit with the licensed partner, and the agent only brokers the URL; a customerKey may be returned once for a new customerId. * Compliance baked into the tools: own-account rule (sending wallet and receiving bank account must be the same person), 18+, Portugal + EU/EEA only, explicitly not the UK. * Beyond this schema: the README describes the wider server — 47 tools total, adding ~24 paid on-chain/crypto data tools (token safety, gas, wallet portfolio, DeFi yields, SEC filings, web reading) and 5 marketplace tools to discover and pay other agents' MCP services or any of ~15,000 public x402 endpoints. * Caveat worth noting: the README says the checkoutUrl is valid ~2 hours, while the schema says ~5 minutes and single-use — a real discrepancy for whoever forwards the link. To install groups selectively, FIATDOCK_TOOLS=ramp gives exactly these four tools.

Which integrations are available for this server?

Integration with Windsurf (Codeium's IDE) to perform non-custodial off-ramp and on-ramp conversions, including quote retrieval, session creation, and order tracking. Integration with CrewAI to perform non-custodial off-ramp and on-ramp conversions, including quote retrieval, session creation, and order tracking. Integration with LangChain to perform non-custodial off-ramp and on-ramp conversions, including quote retrieval, session creation, and order tracking. Integration with OpenAI Agents SDK to perform non-custodial off-ramp and on-ramp conversions, including quote retrieval, session creation, and order tracking.

fiatdock-mcp

Official

by fiatdock

Overview Schema Source Related Servers Discussions Admin

JavaScript

Hybrid

fiatdock-mcp

A marketplace where AI agents discover MCP services and buy them from other agents per call, in USDC. Payment goes over x402 straight to the seller's wallet — no accounts, no API keys, no subscriptions, and FiatDock never holds the money. You are charged only if the seller actually answers: settlement happens AFTER delivery, never before. A call that returns no answer costs you nothing — but an answer you merely dislike is still a delivered call, and is paid. Sellers list for free, and FiatDock's gateway commission is currently waived for every seller — they keep 100% of each paid call (the standard rate is 1%).

Also included: cash out an agent's USDC to a real bank account — its owner receives the money in their own bank account, in any of 18 currencies, with conversion, KYC and custody handled by a licensed payment partner (Mt Pelerin) and FiatDock never touching the funds. It has a floor of about CHF 50, one step only a human can complete, and order status you poll. Plus first-party on-chain Base data and token-safety screening.

Setup — two steps

# 1. Give the agent a payment wallet (the step everyone skips — without it every paid
#    tool stops at an HTTP 402 "payment required" challenge and NOTHING works past free):
#    create a FRESH wallet, fund it with a few USDC on Base, and export its key:
export AGENT_PRIVATE_KEY=0x...   # dedicated low-balance wallet — never your main key

# 2. Run the server — 47 MCP tools over stdio, paid calls settle automatically:
npx -y fiatdock-mcp

No wallet yet? Everything marked free below still works — start with get_quote and token_price, add the wallet when you want the paid tools.

4 ramp tools (USDC ↔ your own bank) + 13 data tools (crypto + on-chain intelligence, a web page reader, an email check) + 5 marketplace tools (discover & call other agents' MCP services — and search & pay ANY x402 endpoint in the public index) — all non-custodial. Take only the group you need with FIATDOCK_TOOLS:

Tool	Cost	What it does
`get_quote`	free	Live rate + the exact amount received, net of every provider fee (incl. the 1% service commission)
`create_offramp_session`	$0.01 USDC via x402	Agent's USDC → owner's own bank account; returns a one-time `checkoutUrl`
`create_onramp_session`	$0.01 USDC via x402	Owner's own fiat → USDC to the agent's wallet (address locked)
`get_order_status`	free	Track an order by `partnerOrderId`
`token_price`	free	Real-time price/liquidity/volume/change for any EVM token by contract address (DexScreener), or a major symbol spot price
`token_safety`	$0.0045 USDC via x402	On-chain safety verdict (honeypot / tax / owner-privilege / holder-concentration) `safe\|caution\|danger` (GoPlus + DexScreener); not charged if data unavailable
`stablecoin_intel`	$0.002 USDC via x402	Stablecoin supply, $1.00 peg deviation & per-chain breakdown incl. Base (DefiLlama); not charged if data unavailable
`gas_price`	$0.001 USDC via x402	Base gas price (wei + gwei)
`block_number`	$0.001 USDC via x402	Base latest block height + timestamp
`eth_balance`	$0.001 USDC via x402	ETH balance of any address on Base
`usdc_balance`	$0.001 USDC via x402	USDC balance of any address on Base
`token_metadata`	$0.002 USDC via x402	ERC-20 name / symbol / decimals / total supply on Base
`tx_status`	$0.001 USDC via x402	Base tx: success or failed, block, confirmations, gas, from/to
`address_intel`	$0.0045 USDC via x402	Enrich any Base address — EOA/contract/ERC-20, nonce, ETH+USDC balance, keyless security verdict (phishing / sanctioned / mixer)
`token_report`	$0.0045 USDC via x402	Full ERC-20 report in ONE call: price + liquidity + volume and the complete safety verdict
`web_read`	$0.0018 USDC via x402	Any public web page as clean text — title, description, canonical, readable body, first 50 links, word count; a page that cannot be read is not charged
`email_check`	$0.001 USDC via x402	Is this email worth sending to? Syntax, DNS (MX, then A/AAAA), disposable / role / free-provider lists, a typo suggestion, a normalized form, a risk verdict with reasons — no SMTP probe
`perp_market`	$0.001 USDC via x402	Hyperliquid perps — mark/oracle price, funding rate + APR, open interest, 24h volume — with the next Binance/Bybit funding beside it
`prediction_markets`	$0.0045 USDC via x402	Live Polymarket odds on any topic — outcome prices (implied probability), volume, liquidity; a search with no match is not charged
`defi_yields`	$0.001 USDC via x402	Best DeFi yields by chain and token (DefiLlama) — APY base vs rewards, 30-day mean, TVL, IL risk
`fx_rates`	$0.001 USDC via x402	Live FX rates and conversion for ~170 currencies, with the ECB reference rate beside each
`wallet_portfolio`	$0.0045 USDC via x402	Every token a Base wallet holds — priced, with a USD total; spam flagged and excluded
`token_holders`	$0.0027 USDC via x402	Top holders of an ERC-20 — contract/locked/burn flags, locked LP, concentration
`domain_intel`	$0.0045 USDC via x402	Registrar, age and expiry (RDAP), DNS, SPF/DMARC and the TLS certificate of any domain
`site_contacts`	$0.0027 USDC via x402	A website's social profiles, role emails (info@, sales@) and tel: phones — persons' addresses never returned
`crypto_news`	$0.001 USDC via x402	Latest crypto headlines from nine newsrooms, filterable by keyword
`sec_filings`	$0.0027 USDC via x402	A US company's latest SEC filings by ticker — 10-K, 10-Q, 8-K items, Form 4 — with sec.gov links
`prompt_injection_check`	$0.0045 USDC via x402	Scan untrusted text for prompt-injection patterns before your agent reads it
`token_screener`	$0.009 USDC via x402	New and boosted tokens from DexScreener's lists — price, liquidity, volume, buys/sells, age
`paper_search`	$0.009 USDC via x402	Academic papers from OpenAlex (Crossref fallback) — authors, year, DOI, citations, abstract
`satellite_scenes`	$0.009 USDC via x402	Latest Sentinel-2 satellite images of any point — date, cloud cover, preview, full image
`seo_audit`	$0.009 USDC via x402	Technical SEO audit of a page — issues by severity and a 0-100 score
`x402_top_services`	$0.009 USDC via x402	The x402 market by seller — est. revenue, paid calls, paying wallets, price
`ens_resolve`	$0.0027 USDC via x402	ENS names and Basenames ↔ addresses, with profile records
`timezone_convert`	$0.001 USDC via x402	One instant in up to 20 IANA time zones, DST-aware
`public_holidays`	$0.001 USDC via x402	A country’s public holidays, and whether a date is one
`weather_forecast`	$0.0018 USDC via x402	Weather forecast for any point (MET Norway)
`wiki_summary`	$0.0018 USDC via x402	Wikipedia article summary in 21 languages
`hn_search`	$0.0027 USDC via x402	Hacker News front page or search
`feed_read`	$0.0022 USDC via x402	Any RSS or Atom feed as JSON items
`package_intel`	$0.0027 USDC via x402	npm / PyPI package safety: OSV vulnerabilities, deprecation, release age
`company_financials`	$0.0045 USDC via x402	A US company’s reported financials (SEC XBRL)
`search_services`	free	Search the FiatDock marketplace of MCP services — matches each listed server's own tool names, not just its description. Returns the top 20 best-matching listings by default (`limit`, max 50); `truncated`/`total` tell you when there are more
`get_service`	free	One listing's full detail + how to call it
`call_service`	per-listing (x402)	Invoke a listed service. Paid calls settle straight to the seller in the x402 payment(s) the 402 lists — one full-price payment while FiatDock's commission is waived (as it currently is for every seller), otherwise the seller's share plus FiatDock's 1% — non-custodially. Pays automatically from `AGENT_PRIVATE_KEY`, or pass your own signed `payment` — see below
`search_x402`	free	Search the public x402 index — every pay-per-call endpoint it lists (~15,000 from hundreds of hosts), ranked by relevance then 30-day paid calls. Each row: URL, indexed price, network, the endpoint's own `payTo`, 30-day calls/payers
`call_x402`	per endpoint (paid to that endpoint)	Pay any index-listed x402 endpoint straight from `AGENT_PRIVATE_KEY` to the endpoint's `payTo` — FiatDock takes no fee and never touches it. Requires `maxPriceUsd` (or `FIATDOCK_MAX_PRICE_USD`): a third-party 402 is the only statement of price, so with no ceiling nothing is signed and the price comes back. Or pass your own signed `payment`

Remote endpoint (no install): https://fiatdock.com/mcp — Streamable HTTP, stateless, CORS-enabled. It holds no key, so paid tools answer with the x402 402 challenge — and you can complete the purchase from there by signing it yourself (below).

Buying with your own wallet

AGENT_PRIVATE_KEY is the easy path, but it is one wallet chosen at install time. If your agent has its own signer — Coinbase AgentKit, a wallet MCP server, anything — buy in two calls on either transport:

1. call_service({id, args})            -> 402: { paymentRequired, howToPay }
2. sign every entry in paymentRequired.accepts, base64 the x402 payload
3. call_service({id, args, payment})   -> the seller's response

Send the same id and args on the second call — the request quoted in the 402 is the request that gets paid for. A caller-supplied payment takes precedence over AGENT_PRIVATE_KEY (and skips FIATDOCK_MAX_PRICE_USD, which exists to bound automatic spending, not yours). A 402 charges nothing — it is the price, not a bill, so retrying is always safe.

Official MCP Registry: com.fiatdock/fiatdock-mcp
No MCP? GET https://fiatdock.com/tools.json — the same tools as OpenAI/Gemini function-calling schemas mapped to the plain REST API.
Per-client setup (Claude Desktop/Code, Cursor, VS Code, Windsurf, Gemini CLI, OpenAI Agents SDK, LangChain, CrewAI): docs/INTEGRATIONS.md · runnable examples: docs/examples/

Compliance (binding): users must be 18+, in Portugal or supported EU/EEA countries (not available in the UK or restricted countries). Own-account rule: the wallet sending crypto and the bank account receiving fiat must belong to the same person — the agent's owner. No third-party funds, no aggregation, no person-to-person transfers. Crypto is volatile; quotes are indicative; nothing here is investment advice. Terms · Privacy · Risk warning

Related MCP server: Grip MCP

Environment

Variable	Required	Purpose
`FIATDOCK_URL`	no (default `https://fiatdock.com`)	FiatDock API base URL
`FIATDOCK_TOOLS`	no (default `all`)	Install only the tool groups you need, so the rest don't take up your agent's context. See below.
`AGENT_PRIVATE_KEY`	only for paid tools	Agent wallet key used to auto-pay the x402 fee — $0.001–$0.009 depending on the tool (ramp sessions $0.01), plus whatever a marketplace seller charges for `call_service`. Without it, the six free tools still work and paid tools return the 402 challenge instead of buying. Use a dedicated low-balance wallet; never your main key.
`FIATDOCK_MAX_PRICE_USD`	no (default: no ceiling)	Price-bait guard for `call_service`: refuse to pay if a paid gateway call's total x402 charge exceeds this many USD. Overridable per call via the `maxPriceUsd` argument.
`FIATDOCK_BUDGET_USD`	no (default: no budget)	Spend cap for the whole process. The total this server may pay automatically, across every paid data tool, the ramp sessions, `call_service` and `call_x402`. A payment that would take the total above it is refused before anything is signed: the tool returns an error with `budgetUsd`, `spentUsd`, `remainingUsd` and `priceUsd`. Counted when a payment is signed, not when it settles, because a signed authorization can be settled until it expires even if the call failed. It resets when the server restarts; to allow more, raise it and restart. A value that is not a number ≥ 0 is treated as 0 (nothing is paid) and said on stderr. A `payment` you sign yourself is never counted or blocked.

Any x402 endpoint — `search_x402` / `call_x402`

The same wallet buys beyond FiatDock's catalog. search_x402 searches the public x402 index (~15,000 priced endpoints, ranked by 30-day paid calls); call_x402 reads the endpoint's own 402, checks it against maxPriceUsd, signs that one requirement and pays the endpoint's payTo directly — no relay, no gateway, no FiatDock fee. The ceiling is required here (unlike call_service, whose gateway prices a listing FiatDock vetted): a third-party 402 is the only statement of price, so with no maxPriceUsd and no FIATDOCK_MAX_PRICE_USD the tool signs nothing and returns the price for your next call.

search_x402({q: "web search", maxPriceUsd: 0.01})            -> results[] with url, priceUsd, payTo, calls30d
call_x402({url, body: {query: "…"}, maxPriceUsd: 0.01})      -> { ok, status, paid, settlement, result }

Pick your tools — `FIATDOCK_TOOLS`

All 47 tools install by default. A tool list is the first thing a model reads, so if you only came for one thing, take only that:

Group	Tools	For
`ramp`	4	Quotes, USDC↔bank sessions, order status
`data`	24	Token price/safety/report/holders, gas, balances, wallet portfolio, tx status, address intelligence, perps + funding, prediction markets, DeFi yields, FX, crypto news, SEC filings, domain intel, website contacts, web page reader, email check, prompt-injection check
`marketplace`	5	Find, inspect and pay for other agents' MCP services — and search/pay any endpoint in the public x402 index

FIATDOCK_TOOLS=ramp                # just the cash-out surface (4 tools)
FIATDOCK_TOOLS=ramp,marketplace    # cash out + buy from other agents (9 tools)
# unset, or "all"                  # everything (47 tools)

An unrecognised value serves all tools rather than none — a typo should never leave you with an empty server. Switching off marketplace also withdraws the fiatdock://catalog resource, so nothing marketplace-related enters your context.

Resources

fiatdock://fees · fiatdock://coverage · fiatdock://catalog — the live marketplace catalog (name, price per call, category, tool count and a sample of tool names), so your agent knows what is for sale without spending a tool call to ask.

Claude Desktop / Cursor / Windsurf / Gemini CLI

All four read the same mcpServers shape (file: claude_desktop_config.json, ~/.cursor/mcp.json, ~/.codeium/windsurf/mcp_config.json, ~/.gemini/settings.json):

{
  "mcpServers": {
    "fiatdock": {
      "command": "npx",
      "args": ["-y", "fiatdock-mcp"],
      "env": { "AGENT_PRIVATE_KEY": "0x..." }
    }
  }
}

Claude Code

claude mcp add fiatdock -e AGENT_PRIVATE_KEY=0x... -- npx -y fiatdock-mcp
# or remote, no install (free tools + x402 challenges):
claude mcp add --transport http fiatdock https://fiatdock.com/mcp

VS Code (Copilot agent mode)

.vscode/mcp.json:

{
  "servers": {
    "fiatdock": { "type": "stdio", "command": "npx", "args": ["-y", "fiatdock-mcp"], "env": { "AGENT_PRIVATE_KEY": "0x..." } }
  }
}

OpenAI Agents SDK / LangChain / CrewAI

All three consume MCP servers natively — point them at npx -y fiatdock-mcp (stdio) or https://fiatdock.com/mcp (Streamable HTTP):

# OpenAI Agents SDK
from agents.mcp import MCPServerStdio
async with MCPServerStdio(params={"command": "npx", "args": ["-y", "fiatdock-mcp"],
                                  "env": {"AGENT_PRIVATE_KEY": "0x..."}}) as fiatdock: ...

# LangChain (langchain-mcp-adapters)
from langchain_mcp_adapters.client import MultiServerMCPClient
client = MultiServerMCPClient({"fiatdock": {"transport": "streamable_http", "url": "https://fiatdock.com/mcp"}})

# CrewAI (crewai-tools)
from crewai_tools import MCPServerAdapter
tools = MCPServerAdapter({"url": "https://fiatdock.com/mcp", "transport": "streamable-http"})

How a typical off-ramp flows

get_quote (free) — agent checks the rate and the full fee breakdown.
create_offramp_session — pays $0.01 in USDC automatically via x402, receives checkoutUrl + partnerOrderId.
The agent forwards checkoutUrl to its human owner (valid ~2 hours). The owner gives the provider a phone number and email; identity documents are needed only above ~CHF 999 per rolling 30 days — no account, no password.
get_order_status (or a signed callback) confirms COMPLETED.

Security

Found a vulnerability? Please report it privately to osama@fiatdock.com — see SECURITY.md. Never open a public issue for security reports.

License

MIT

Available Tools

4 tools

create_offramp_sessionCreate off-ramp session (USDC → bank)AInspect

Convert the agent's USDC to fiat in the owner's OWN bank account. Returns a one-time checkoutUrl (forward it to the human owner; valid 5 minutes, single use) and a partnerOrderId to track. COMPLIANCE: own-account rule — the sending wallet and the receiving bank account must belong to the SAME person (the agent's owner); no third-party funds, no aggregation, no P2P transfers. 18+; service area: Portugal + Transak-supported EU/EEA countries (NOT the UK). Crypto is volatile; not investment advice.

ParametersJSON Schema

Name	Required	Description
`ref`	No	Optional referral code (1-64 chars: letters, digits, _ or -)
`email`	No	Owner's Transak account email
`network`	No	USDC network, default base
`customerId`	No	Stable agent/customer id
`cryptoAmount`	Yes	USDC amount to sell
`fiatCurrency`	No	e.g. EUR, default EUR

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No	Next-step instructions
`checkoutUrl`	Yes	One-time branded checkout URL (valid ~5 minutes, single use) — forward to the human owner
`customerKey`	No	Returned ONCE on the first session with a new customerId — store securely
`partnerOrderId`	Yes	Order id — track it with get_order_status
`customerKeyNote`	No	How to use customerKey

TDQS

A4.4/5.0

Behavior5/5

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

The description discloses far more than the annotations: one-time URL valid for 5 minutes, single-use, partnerOrderId tracking, own-account compliance, service area exclusions, and a legal disclaimer. These details go well beyond the sparse annotations (readOnlyHint=false, openWorldHint=true, etc.) and provide crucial behavioral context. No contradictions with annotations exist.

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 description is reasonably concise for the amount of information it conveys. It front-loads the primary action and output, then adds compliance and service-area details in a structured way. The compliance section is long but carries critical constraints, so each sentence earns its place. Could be slightly tightened, but overall efficient.

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?

The description covers the core flow (convert USDC → fiat, return checkoutUrl), the compliance rules, service area, age restriction, and the nature of the output (one-time, valid 5 minutes). Since the output schema exists, return values don't need further detailing. It is complete for an agent to decide when to invoke and how to handle the response.

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 all parameters are already explained in the schema. The description adds no parameter-specific details (e.g., the meaning of 'cryptoAmount' is already stated as 'USDC amount to sell'). Per the rubric baseline, this is a 3; the tool description does not add extra value to parameter understanding.

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 core action: 'Convert the agent's USDC to fiat in the owner's OWN bank account.' It distinguishes itself from the sibling 'create_onramp_session' by specifying the off-ramp direction, and it names the primary outputs (checkoutUrl, partnerOrderId). This gives a precise and unique purpose.

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 gives explicit context for use: the agent should forward the checkout URL to the human owner, and it lists compliance constraints (own-account rule, 18+, service area) that define when it is permissible. It does not explicitly name 'use get_quote for pricing first' or 'instead of create_onramp_session', but the opposite direction is implied by the sibling name, so the when-to-use is clear enough.

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

create_onramp_sessionCreate on-ramp session (fiat → USDC)AInspect

Buy USDC with the owner's OWN fiat and deliver it to the agent's wallet (address locked). Returns checkoutUrl + partnerOrderId. COMPLIANCE: own-account rule — the sending wallet and the receiving bank account must belong to the SAME person (the agent's owner); no third-party funds, no aggregation, no P2P transfers. 18+; service area: Portugal + Transak-supported EU/EEA countries (NOT the UK). Crypto is volatile; not investment advice.

ParametersJSON Schema

Name	Required	Description
`ref`	No	Optional referral code (1-64 chars: letters, digits, _ or -)
`email`	No	Owner's Transak account email
`network`	No	USDC network, default base
`customerId`	No	Stable agent/customer id
`fiatAmount`	Yes	Fiat amount to spend
`fiatCurrency`	No	e.g. EUR, default EUR
`walletAddress`	Yes	Agent wallet that receives USDC

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No	Next-step instructions
`checkoutUrl`	Yes	One-time branded checkout URL (valid ~5 minutes, single use) — forward to the human owner
`customerKey`	No	Returned ONCE on the first session with a new customerId — store securely
`partnerOrderId`	Yes	Order id — track it with get_order_status
`customerKeyNote`	No	How to use customerKey

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=false and openWorldHint=true, and the description adds important behavioral context beyond those flags: the wallet address is locked after session creation, compliance rules are enforced, and the transaction is not reversible (implied by 'own-account rule'). Includes a risk disclaimer. No contradiction with 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?

The description is longer than typical but organized into clear segments: function, return values, compliance, service area, disclaimer. Each sentence adds value—no filler. The compliance and geographic restrictions are critical for the agent to avoid errors.

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?

Despite having 7 parameters and an output schema (not shown), the description covers the essential context: what the session does, what it returns, compliance constraints, and service area. It doesn't detail error behavior, but the output schema likely covers return structure. The compliance and exclusion information is unusually complete.

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?

The schema has 100% coverage with descriptions for all 7 parameters, so the baseline is 3. The description adds extra semantics by clarifying that 'walletAddress' is the receiving agent wallet (locked) and that fiat is the owner's own funds. It enriches meaning without repeating schema details.

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 function: buying USDC with the owner's own fiat and delivering to the agent's wallet. It specifies the return values (checkoutUrl + partnerOrderId) and distinguishes from the sibling create_offramp_session by explicitly framing this as an on-ramp operation.

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 provides explicit context on when to use the tool: for fiat-to-USDC purchases, and includes compliance restrictions (own-account rule, no third-party funds) and geographic limitations (Portugal + Transak-supported EU/EEA, NOT the UK). It doesn't explicitly mention alternatives, but the name and purpose make the on-ramp context clear.

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

get_order_statusGet order statusA

Read-onlyIdempotent

Inspect

Check the status of an on/off-ramp order by partnerOrderId.

ParametersJSON Schema

Name	Required	Description	Default
`partnerOrderId`	Yes	Order id returned when the session was created

Output Schema

ParametersJSON Schema

Name	Required	Description
`ref`	No	Referral code if one was set
`status`	Yes	SESSION_CREATED -> PROCESSING -> COMPLETED \| FAILED \| CANCELLED \| EXPIRED
`createdAt`	No	ISO 8601 session creation time
`updatedAt`	No	ISO 8601 time of the last webhook update
`customerId`	No	Customer id the session was created with
`isBuyOrSell`	No	Order direction

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, establishing the safety profile. The description adds no extra behavioral context such as error handling, data freshness, or side effects, but it doesn't contradict the annotations either. Neutral value.

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?

A single, clear sentence that is front-loaded with the action and resource. Every word earns its place, with no redundancy or 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?

Despite an output schema existing, the description doesn't detail possible status values or error responses, but for a simple lookup tool with a defined output schema, the description is sufficient. It doesn't need to explain return values, and the low complexity keeps this complete.

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 coverage is 100%, and the only parameter (partnerOrderId) already has a descriptive definition in the schema. The description merely restates 'by partnerOrderId' without adding new semantics, so it meets the baseline but adds no value.

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 identifies the action ('Check the status') and the resource ('on/off-ramp order') keyed by partnerOrderId. It distinguishes from sibling tools, which are creation/quote operations, making the purpose unmistakable.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention exclusions, prerequisites, or suggest other tools for related scenarios, leaving the agent to infer usage from context alone.

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

get_quoteGet a free quoteA

Read-onlyIdempotent

Inspect

Free quote before paying: exchange rate, total fees (all itemised, incl. the 1% service commission), and amount received. Quotes are indicative, not guaranteed. side=SELL (USDC->fiat) or BUY (fiat->USDC).

ParametersJSON 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

ParametersJSON Schema

Name	Required	Description
`note`	No	Human-readable caveat (quotes are indicative)
`rate`	Yes	Exchange rate used (fiat per USDC)
`side`	Yes	Quote direction
`network`	No	USDC network the quote assumes
`youSend`	Yes	Amount the sender pays, e.g. '50 USDC'
`totalFee`	Yes	Total fees in fiat, all itemised (incl. the 1% service commission)
`youReceive`	Yes	Amount received after all fees, e.g. '44.6 EUR'
`feeBreakdown`	Yes	Provider's itemised fee list
`paymentMethod`	No	Settlement method, e.g. sepa_bank_transfer

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the bar is lower. The description adds valuable context beyond these: 'Quotes are indicative, not guaranteed' warns about quote volatility, and it details fee structure (1% commission, itemised). This is more than simple rephrasing of annotations.

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?

Two sentences plus a side explanation, with each part earning its place. Front-loads the core purpose ('Free quote before paying'), then lists contents, caveat, and side semantics. No fluff or redundancy.

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 an output schema exists (so return format is covered) and annotations are strong, the description provides sufficient context: purpose, expected data (rate, fees, amount), caveat about quotes, and side meaning. It could mention expiration or side-specific required amounts, but those are in the schema, so it remains complete enough.

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 baseline is 3. The description's side notation (SELL/BUY) mirrors the schema's enum description, adding no new insight. It does not elaborate on required parameters (e.g., cryptoAmount for SELL) beyond what the schema already states, so it provides no additional parameter meaning.

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 opens with 'Free quote before paying', clearly stating the tool's purpose: to obtain an exchange rate, itemized fees, and amount received. This distinguishes it from siblings (create_offramp_session, create_onramp_session, get_order_status) as the pre-payment quote step, not a session creation or order status lookup.

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 phrase 'before paying' gives clear timing context, indicating this tool is for pre-transaction estimation. It does not explicitly exclude alternatives, but the context is sufficient to understand when to use it versus siblings. A more explicit alternative would earn a 5.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.2.0Aug 1, 2026
- First observedcreate_offramp_session
- First observedcreate_onramp_session
- First observedget_order_status
- First observedget_quote

Deploy Server

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

TDQS

A4.2/5.0

Scored 2026-08-01 18:10 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: creating offramp and onramp sessions are opposite directions, get_quote provides pricing for both sides, and get_order_status tracks orders. No overlap or ambiguity.

Naming Consistency5/5

All names follow a consistent verb_noun snake_case pattern: create_offramp_session, create_onramp_session, get_quote, get_order_status. The verb prefixes (create/get) and noun suffixes are uniform.

Tool Count5/5

Four tools is well-scoped for a focused off/on-ramp service, covering the essential operations without bloat. Each tool earns its place.

Completeness4/5

Core lifecycle is covered: quote, create session (both directions), and check status. Minor gaps exist like cancel/refund or listing orders, but these are not essential for the primary flow.

Maintenance

ActivityActive

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

AGORA Omega A
com.agoraverify
Pay-per-call checks for AI agents: sanctions, MiCA, French KYB, AI Act. USDC via x402.
Legal & Compliance Security Payments & Billing
81
GoCreative Agent API B
io.github.ColinHughes2121
17-model LLM gateway + 350+ data/KYB/sanctions tools. Pay-per-call USDC via x402, no API key.
Social Media Cryptocurrency
2
Tollbooth Swap API A
xyz.tollboothswap.api
Token swaps and honeypot/rug checks for AI agents on 8 chains, paid per-call in USDC via x402.
Cryptocurrency Blockchain Web3 & Decentralized Tech
11
Portugal Payments (Stripe — Multibanco)A
app.wishpool
Portugal payments for AI agents — Multibanco via Stripe. Never holds funds.
Payments & Billing Finance
2

Related MCP Servers

pay-mcp
Payments & Billing Blockchain Web3 & Decentralized Tech
pay-skill
A
license
Not graded
quality
B
maintenance
USDC payments for AI agents on Base. Direct transfers, pre-funded tabs, x402 paywall handling, and service discovery.
Updated 11 days ago (2026-10-05 02:07 UTC)
102 npm
MIT
Grip MCPofficial
Cryptocurrency Blockchain Payments & Billing
grip-foundation
A
license
A
quality
D
maintenance
Provides a non-custodial USDC wallet on Base for AI agents, with human-in-the-loop approval for every payment.
Updated 6 months ago (2026-04-28 03:20 UTC)
4
6 npm
MIT
hyperd-mcpofficial
Blockchain Cryptocurrency Web3 & Decentralized Tech
hyperd-ai
A
license
A
quality
D
maintenance
Pre-trade DeFi intelligence for AI agents. 20 paid x402 endpoints, USDC on Base.
Updated 4 months ago (2026-06-09 22:01 UTC)
23
90 npm
1
MIT
Brighty MCP Server
Finance Payments & Billing
razz-team
A
license
Not graded
quality
C
maintenance
Banking infrastructure for AI agents: open accounts, issue cards, send SEPA/SWIFT payments, run mass payouts, and pay invoices via natural language.
Updated 2 months ago (2026-08-12 20:36 UTC)
2
MIT

fiatdock-mcp

Setup — two steps

Buying with your own wallet

Environment

Any x402 endpoint — search_x402 / call_x402

Pick your tools — FIATDOCK_TOOLS

Resources

Claude Desktop / Cursor / Windsurf / Gemini CLI

Claude Code

VS Code (Copilot agent mode)

OpenAI Agents SDK / LangChain / CrewAI

How a typical off-ramp flows

Security

License

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

pay-mcp

Grip MCPofficial

hyperd-mcpofficial

Brighty MCP Server

Any x402 endpoint — `search_x402` / `call_x402`

Pick your tools — `FIATDOCK_TOOLS`