FiatDock
Server Details
Non-custodial USDC <-> bank for AI agents via x402 + Transak. Own funds only; PT + EU/EEA; 18+.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 7 of 7 tools scored. Lowest: 3.8/5.
Each tool serves a clearly distinct purpose: call_service invokes marketplace services, create_offramp_session and create_onramp_session handle financial conversions, get_order_status tracks orders, get_quote provides pricing, get_service and search_services handle marketplace browsing. There is no overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., call_service, create_offramp_session, get_order_status). No deviations or mixed conventions.
With 7 tools, the set is well-scoped for the server's purpose: covering marketplace browsing, service invocation, financial conversions, and order tracking. No superfluous or missing tools for the apparent domain.
The tool surface covers core workflows: browse services, invoke them, get quotes, create on/off-ramp sessions, and check order status. Minor gaps exist (no ability to list all orders or cancel sessions), but these do not severely hinder typical usage.
Available Tools
10 toolscall_serviceCall a marketplace serviceAInspect
Invoke a listed FiatDock service. PAID listings go THROUGH the gateway (POST /s/:id) so the non-custodial split is enforced — normally TWO payments (99% seller + 1% FiatDock), or ONE full-price payment to the seller during that seller's first-month 0% launch window; this remote /mcp cannot sign payments, so it returns the gateway's 402 challenge as an error (use the fiatdock-mcp npm package with AGENT_PRIVATE_KEY to pay whatever the 402 lists automatically). FREE / first-party listings are forwarded to their real MCP endpoint directly (no payment). Pass the service's expected request body as args.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Listing id (svc_…) to invoke, from search_services | |
| args | No | JSON payload to send to the service (e.g. an MCP JSON-RPC request body) — shape is defined by that service |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | true when the underlying service returned a 2xx |
| result | No | The service's response body — parsed JSON when it returned JSON, otherwise the raw text |
| status | Yes | HTTP status returned by the service (or the gateway) |
| service | Yes | Listing id that was invoked |
| routedThroughGateway | Yes | true if PAID (settled 99% seller / 1% FiatDock via /s/:id); false if FREE/first-party direct |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only and non-destructive behavior, but the description adds crucial details: paid listings go through a gateway, the tool cannot sign payments, and returns a 402 error if no key. This fully discloses the tool's behavioral traits beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise and front-loaded with the main action. It contains necessary details without redundancy, though it could be slightly shorter. Still, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the complexity of payment handling and two execution paths, the description covers all relevant scenarios, return behavior, and required setup. The presence of an output schema reduces the burden, but the description remains comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for id and args. The description restates some of this (e.g., id from search_services) but does not add significant new meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: to invoke a FiatDock service. It distinguishes between paid and free listings, explaining the different paths (gateway vs direct MCP), which differentiates it from sibling tools like search_services or get_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool, including handling of paid vs free services, the need for AGENT_PRIVATE_KEY for paid services, and what happens with the 402 challenge. It also mentions the fiatdock-mcp npm package as an alternative for payment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. Paid endpoint ($0.05 USDC via x402) — without payment this returns the 402 challenge; use the fiatdock-mcp npm package with AGENT_PRIVATE_KEY for automatic payment. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Optional referral code (1-64 chars: letters, digits, _ or -) | |
| 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
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation readOnlyHint=false is consistent. Description adds critical behavioral context: paid endpoint via x402, returns a one-time checkoutUrl valid 5 minutes, partnerOrderId for tracking, and compliance rules (own-account, 18+, service area). No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then returns info, payment handling, and compliance. Every sentence adds value, though slightly verbose. Well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, payment, compliance), the description covers purpose, usage, behavioral traits, return values (checkoutUrl, partnerOrderId), and constraints. The output schema existence is noted but description already mentions key return fields, making it complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good individual parameter descriptions. The tool description does not significantly enhance parameter semantics beyond the schema, providing only overarching context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts USDC to fiat into the owner's bank account, distinguishing it from the sibling create_onramp_session (which likely does the opposite). The verb 'convert' is specific, and the resource and direction are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly details when to use (for owner's own bank account) and when not to (no third-party, no aggregation, not in UK). Also explains payment requirement and how to handle the 402 challenge, guiding the agent on prerequisites and alternatives.
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. Paid endpoint ($0.05 USDC via x402) — without payment this returns the 402 challenge; use the fiatdock-mcp npm package with AGENT_PRIVATE_KEY for automatic payment. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Optional referral code (1-64 chars: letters, digits, _ or -) | |
| 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
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant details beyond annotations: paid endpoint, return values, compliance, region, volatility disclaimer. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but well-structured: purpose, returns, payment, compliance, region, disclaimer. Efficiently packed with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects for a pay-on-ramp tool: purpose, payment flow, compliance, service area, risk disclaimer. Output schema provides additional detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage). Description adds context but doesn't enhance parameter understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool buys USDC with owner's fiat and delivers to agent wallet, distinguishing it from offramp and other sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies use case (buy USDC with owner's fiat), payment requirement (x402), and compliance rules. Lacks explicit when-not-to-use or alternatives, but offers good context.
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 statusARead-onlyIdempotentInspect
Check the status of an on/off-ramp order by partnerOrderId.
| Name | Required | Description | Default |
|---|---|---|---|
| partnerOrderId | Yes | Order id returned when the session was created |
Output 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. The description 'check the status' is consistent but adds no extra behavioral context beyond what annotations convey. For a simple read operation, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no unnecessary information. It is concise and front-loads the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a full output schema and comprehensive annotations, the description is sufficient for a simple status-check tool. It could mention potential error conditions, but overall it provides a complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description in the schema is clear. The tool description does not add additional parameter semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Check') and the resource ('status of an on/off-ramp order') and identifies the key parameter (partnerOrderId). It implicitly distinguishes from siblings which create sessions or get quotes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking order status when you have a partnerOrderId, but it does not explicitly state when to use or not use it, or contrast with siblings. No 'use this when' or 'instead of' guidance.
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 quoteARead-onlyIdempotentInspect
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).
| 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
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, openWorld. The description adds critical behavioral context that quotes are indicative and not guaranteed, which is not covered by annotations. This supplements the safe-read behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences plus an explanatory note on side parameter. It is front-loaded with the tool's purpose and includes all essential information without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a quote tool with 5 parameters, an output schema, and full schema coverage, the description fully covers the tool's purpose, key behaviors, and parameter usage. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage. The tool description adds value by explaining the side enum semantics (SELL=USDC->fiat, BUY=fiat->USDC) and clarifying which amount parameter applies per side (fiatAmount for BUY, cryptoAmount for SELL), going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a free quote with exchange rate, total fees itemized, and amount received. It distinguishes from sibling tools (create_offramp_session, create_onramp_session, get_order_status) by focusing on quote generation before payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates this tool is used before paying and explains the side parameter (SELL/BUY) with direction. It provides clear context on when to use each side, but does not explicitly mention when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_serviceGet a marketplace service's detailARead-onlyIdempotentInspect
Full detail for one FiatDock marketplace listing, including how to call it: PAID listings route through the gateway via call_service (the 99/1 split is enforced); FREE/first-party listings expose their real MCP endpoint to call directly. Read-only, free.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Listing id (svc_…) from search_services |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Listing id (svc_…) — pass to get_service / call_service |
| name | Yes | Service name |
| tags | No | Free-text tags |
| feeBps | No | Effective gateway commission in basis points right now: 0 during the seller's first-month launch waiver (buyer pays the FULL price directly to the seller), else 100 (1%). PAID listings only (ADR-0022). |
| rating | No | Verified-purchase rating aggregate: { count, average (1-5) } |
| status | No | Listing status: pending | verified | suspended |
| reviews | No | Recent verified-purchase reviews, newest first |
| summary | No | One-line summary |
| callHint | No | Plain-language instruction for how an agent invokes this listing |
| category | No | Category slug (data, search, finance, dev, productivity, ai, web, other) |
| networks | No | Chain slugs the service settles on |
| priceUsd | Yes | Price per call in US dollars (0 = free) |
| sellerId | No | Opaque seller id that owns the listing |
| verified | Yes | Verified seller (KYC + active badge) or first-party (platform-vouched) |
| createdAt | No | ISO 8601 listing creation time |
| firstParty | No | Platform's own featured listing (official) |
| gatewayUrl | Yes | How to reach it: a relative /s/:id (PAID — invoke via call_service, 99/1 split) OR an absolute MCP endpoint URL (FREE/first-party — call directly) |
| sellerName | No | Seller display name, if set |
| description | No | Full description |
| mcpEndpoint | No | Real MCP endpoint — present only for FREE/first-party (direct) listings |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral context (paid vs free routing, 99/1 split enforcement, read-only, free) beyond annotations (readOnlyHint, idempotentHint). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler, front-loaded with the main purpose and key distinction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter, output schema, and robust annotations, the description covers the necessary behavioral distinction for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter description. Description does not add further parameter details, but schema alone is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full detail for one marketplace listing, differentiating it from siblings like call_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use this tool vs call_service: paid listings route through call_service, free/first-party can be called directly. No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_servicesSearch the FiatDock marketplaceARead-onlyIdempotentInspect
Find paid + free MCP services other agents have published on the FiatDock marketplace. Returns matching listings (id, name, summary, price, category, seller, verified, gatewayUrl). Use get_service for full detail and call_service to invoke one. Read-only, free.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text search over name, summary, description and tags | |
| sort | No | Sort order (default newest; first-party listings are always featured first) | |
| category | No | Filter by category slug: data, search, finance, dev, productivity, ai, web, other | |
| verifiedOnly | No | Only verified listings (KYC'd seller or first-party) |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of listings returned |
| services | Yes | Matching listings (first-party featured first) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by listing the returned fields (id, name, summary, price, etc.) and reiterating the read-only and free nature, complementing the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous information. It front-loads the purpose and efficiently covers usage guidance and behavioral attributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage, rich annotations, and an output schema, the description provides sufficient context: it specifies returned fields, usage alternatives, and the read-only/free nature, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described in the schema. The description does not add extra meaning beyond the schema, so it meets the baseline for a well-covered schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds MCP services on the FiatDock marketplace, using a specific verb and resource. It also distinguishes between siblings by referencing get_service and call_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using get_service for full detail and call_service to invoke, providing clear alternatives. It also notes the tool is read-only and free, but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stablecoin_intelStablecoin intelligence ($0.002)ARead-onlyIdempotentInspect
PAID ($0.002 USDC via x402). Supply, peg health and per-chain breakdown for USDC and other stablecoins: total circulating supply, deviation from the $1.00 peg, peg mechanism, the amount circulating on Base (with its share of total) and the top chains by supply (DefiLlama). A treasury/payments agent uses it to check its settlement asset is healthy. Without payment this returns the 402 challenge; the fiatdock-mcp npm package pays automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | Stablecoin symbol (default USDC), e.g. USDC, USDT, DAI, USDe |
Output Schema
| Name | Required | Description |
|---|---|---|
| asOf | Yes | |
| name | No | |
| note | No | |
| asset | Yes | Stablecoin symbol |
| price | Yes | Current price in USD |
| onBase | Yes | Circulating supply on Base + its share of total |
| source | Yes | |
| pegStatus | Yes | on-peg | slight-deviation | off-peg | unknown |
| topChains | Yes | Top chains by circulating supply |
| pegMechanism | No | e.g. fiat-backed, crypto-backed, algorithmic |
| pegDeviationPct | Yes | Absolute deviation from $1.00, % |
| totalCirculatingUsd | Yes | Total circulating supply (USD) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it requires payment ($0.002 via x402), returns a 402 challenge without payment, and notes that the npm package pays automatically. Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but includes necessary payment details. It front-loads the paid nature and then lists capabilities. Could be slightly more compact, but no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description does not need to explain return values. It covers the data returned, payment flow, and use case. Annotations cover safety traits, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description already covering symbol and default. The tool description mentions examples but does not add new semantic value beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides supply, peg health, and per-chain breakdown for stablecoins. It distinguishes itself from sibling tools like call_service and create_offramp_session by being the only stablecoin intelligence tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies a use case ('treasury/payments agent uses it to check its settlement asset is healthy') and explains the payment mechanism. It does not explicitly list when not to use, but the context of siblings makes the tool's purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
token_priceToken price & liquidity (free)ARead-onlyIdempotentInspect
FREE real-time price snapshot for any EVM token by contract address: USD price, 5m/1h/6h/24h change, liquidity, 24h volume, market cap/FDV and the most-liquid DEX pair (DexScreener). Or pass a major symbol (ETH/BTC) for a Coinbase spot price. Read-only, free.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain slug: base (default), ethereum, polygon, arbitrum, optimism, bsc, avalanche | |
| token | No | ERC-20 contract address (0x…) — preferred | |
| symbol | No | Major asset symbol (e.g. ETH, BTC) — used when no contract address is given |
Output Schema
| Name | Required | Description |
|---|---|---|
| asOf | Yes | ISO 8601 time the snapshot was read |
| name | No | Token name |
| note | No | |
| chain | No | Chain the quoted pair trades on |
| fdvUsd | No | Fully-diluted valuation in USD |
| source | Yes | Data source |
| symbol | No | Token symbol |
| topPair | No | The most-liquid DEX pair used |
| priceUsd | Yes | Current USD price (most-liquid pair) |
| priceChange | No | Percent price change by window |
| liquidityUsd | No | Pair liquidity in USD |
| marketCapUsd | No | Market cap in USD |
| volume24hUsd | No | 24h trading volume in USD |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, openWorldHint, idempotentHint. The description adds value by stating 'FREE', 'real-time', 'DexScreener' as source, and 'Coinbase spot price' for major symbols, along with time intervals for changes. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but packs all essential information: purpose, inputs, outputs, constraints. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, the description covers return values (price, changes, liquidity, volume, market cap, DEX pair). Annotations cover behavioral aspects, making it complete for a read-only, free price tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds meaning by explaining that token is preferred over symbol, chain slug with default, and what major symbols are. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 real-time price snapshot for any EVM token by contract address or major symbol. It specifies the outputs (USD price, changes, liquidity, volume, market cap, DEX pair) and distinguishes from sibling tools like stablecoin_intel and token_safety.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool: for any EVM token by contract address or for major symbols (ETH/BTC). It is implied that this is the tool for price data, but it doesn't explicitly state alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
token_safetyToken safety & rug check ($0.01)ARead-onlyIdempotentInspect
PAID ($0.01 USDC via x402). On-chain safety verdict for any EVM token BEFORE you trade it: honeypot detection, buy/sell tax, contract-verified, owner privileges (mint / blacklist / pausable / hidden owner / balance-modify), holder concentration, LP-locked %, CEX listing and live DEX liquidity (GoPlus Security + DexScreener). Returns verdict safe|caution|danger with the exact risks. Without payment this returns the 402 challenge; the fiatdock-mcp npm package (AGENT_PRIVATE_KEY) pays automatically. Not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain slug: base (default), ethereum, polygon, arbitrum, optimism, bsc, avalanche | |
| token | Yes | ERC-20 contract address (0x…) to screen |
Output Schema
| Name | Required | Description |
|---|---|---|
| asOf | Yes | |
| name | No | Token name |
| note | No | |
| risks | Yes | Each detected risk: level (danger|caution), flag, detail |
| source | Yes | |
| symbol | No | Token symbol |
| isProxy | No | Upgradeable proxy contract |
| verdict | Yes | Overall risk verdict |
| buyTaxPct | Yes | Buy tax % |
| isHoneypot | Yes | Token cannot be sold (honeypot) |
| isMintable | No | Supply can be minted |
| sellTaxPct | Yes | Sell tax % |
| holderCount | No | Number of holders |
| lpLockedPct | No | Liquidity-pool tokens locked, % |
| isOpenSource | Yes | Contract source verified/open |
| liquidityUsd | No | DEX liquidity in USD |
| topHolderPct | No | Top holder's share of supply, % |
| verdictReason | Yes | Plain-language explanation of the verdict |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, idempotentHint) are consistent with a read-only, non-destructive operation. The description adds transparency on payment behavior ($0.01 USDC, 402 challenge without payment) and disclaimer (not financial advice), beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but concise, covering payment, functionality, and return format in two sentences. It front-loads key information (paid, purpose) and is structured efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (paid operation, specific payment method, multiple checks), the description fully explains the payment flow, the scope of checks, and the verdict output. It is complete without requiring additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds context: chain defaults to base, token is an ERC-20 contract address. This provides value beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool provides an on-chain safety verdict for EVM tokens before trading, listing specific checks like honeypot detection, taxes, owner privileges, etc. It clearly distinguishes itself from sibling tools like token_price by focusing on safety screening.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies usage 'BEFORE you trade it' and mentions the payment requirement via x402. While it doesn't explicitly state when not to use it or compare directly to siblings, the context makes its purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!