What can you do with this server?

FiatDock MCP lets an agent cash USDC out to its owner's bank account, buy USDC, and access crypto data and paid marketplace services, all with automatic USDC micropayments over x402. * Ramp tools: get free quotes, create off-ramp (USDC → bank) and on-ramp (fiat → USDC) sessions, and track order status. * Data tools: real-time token prices, token safety/honeypot checks, stablecoin intelligence, gas price, block number, ETH/USDC balances, token metadata, transaction status, address intelligence, and full token reports. * Marketplace tools: search and inspect other agents' MCP services, then call and pay them per request in USDC. * Payments: paid tools auto-settle via AGENT_PRIVATE_KEY or a caller-supplied signed x402 payment; free tools work without a wallet. * Deployment: run locally via npx -y fiatdock-mcp (stdio) or use the remote endpoint https://fiatdock.com/mcp.

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

Cash out an agent's USDC to a real bank account. Your agent holds USDC, and its owner receives the money in their own bank account, in any of 18 currencies — conversion, KYC and custody handled by a licensed payment partner (Mt Pelerin), and FiatDock never touches the funds. No FiatDock account and no API key.

Also included: first-party on-chain Base data and token-safety screening, and a marketplace where agents discover and pay each other per call in USDC over x402 — settlement goes straight to the seller's wallet, so there are no accounts, no API keys and no subscriptions.

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 — 18 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) + 11 data tools (crypto + on-chain intelligence) + 3 marketplace tools (discover & call other agents' MCP services) — 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.01 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.005 USDC via x402	Enrich any Base address — EOA/contract/ERC-20, nonce, ETH+USDC balance, keyless security verdict (phishing / sanctioned / mixer)
`token_report`	$0.05 USDC via x402	Full ERC-20 report in ONE call: price + liquidity + volume and the complete safety verdict
`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 99% → seller + 1% → FiatDock (100% → seller during that seller's first month), non-custodially. Pays automatically from `AGENT_PRIVATE_KEY`, or pass your own signed `payment` — see below

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.05 depending on the tool, plus whatever a marketplace seller charges for `call_service`. Without it, the five 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.

Pick your tools — `FIATDOCK_TOOLS`

All 18 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`	11	Token price/safety/report, gas, balances, tx status, address intelligence
`marketplace`	3	Find, inspect and pay for other agents' MCP services

FIATDOCK_TOOLS=ramp                # just the cash-out surface (4 tools)
FIATDOCK_TOOLS=ramp,marketplace    # cash out + buy from other agents (7 tools)
# unset, or "all"                  # everything (18 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

ActivityMaintained

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

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
1722
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
systemprompt.io reports A
io.systemprompt
Paid EU AI Act compliance reports for agents. $1.50 per call via x402 (USDC on Base) or Stripe.
Legal & Compliance AI & Machine Learning
22

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 2 days ago (2026-09-21 02:10 UTC)
37 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 5 months ago (2026-04-28 03:20 UTC)
4
3 npm
MIT
hyperd-mcpofficial
Blockchain Cryptocurrency Web3 & Decentralized Tech
hyperd-ai
A
license
A
quality
C
maintenance
Pre-trade DeFi intelligence for AI agents. 20 paid x402 endpoints, USDC on Base.
Updated 3 months ago (2026-06-09 22:01 UTC)
23
29 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 a month ago (2026-08-12 20:36 UTC)
2
MIT

fiatdock-mcp

Setup — two steps

Buying with your own wallet

Environment

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

Pick your tools — `FIATDOCK_TOOLS`