FiatDock

Token safety & rug check ($0.0045)

token_safety

Read-onlyIdempotent

PAID ($0.0045 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.

Input Schema

TableJSON Schema

Name	Required	Description
`chain`	No	Chain slug: base (default), ethereum, polygon, arbitrum, optimism, bsc, avalanche
`token`	Yes	ERC-20 contract address (0x…) to screen
`payment`	No	Base64 of a single x402 v2 PaymentPayload (EIP-3009 transferWithAuthorization on Base USDC). OMIT it on the first call: the 402 you get back carries `howToPay.payloadTemplate` — the exact envelope to fill in — plus the price and the EIP-712 domain. Send it on the second call to complete the purchase; it is forwarded as the PAYMENT-SIGNATURE header, never as body data. Nothing is charged for the 402 itself, and a call that fails after payment settles nothing.

Output Schema

TableJSON Schema

Name	Required	Description
`asOf`	Yes	ISO 8601 time the source data was read (a cached read can be up to a minute old)
`name`	No	Token name
`note`	No	Human-readable caveat about the verdict, if any
`chain`	No	Chain the token was screened on
`query`	No	The resolved lookup this verdict answers
`risks`	Yes	Each detected risk: level (danger\|caution), flag, detail
`token`	No	Contract address that was screened
`source`	Yes	Data source (e.g. GoPlus Security + DexScreener)
`symbol`	No	Token symbol
`isProxy`	No	Upgradeable proxy contract
`verdict`	Yes	Overall risk verdict
`priceUsd`	No	Current USD price, when a liquid pair exists
`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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 25, 2026

changedOutput schema / properties / asOf / description

Previous value: -"ISO 8601 time the verdict was computed"New value: +"ISO 8601 time the source data was read (a cached read can be up to a minute old)"

Changed1 schema field changedAug 23, 2026

addedInput schema / properties / payment

Added value: +{
+  "description": "Base64 of a single x402 v2 PaymentPayload (EIP-3009 transferWithAuthorization on Base USDC). OMIT it on the first call: the 402 you get back carries `howToPay.payloadTemplate` — the exact envelope to fill in — plus the price and the EIP-712 domain. Send it on the second call to complete the purchase; it is forwarded as the PAYMENT-SIGNATURE header, never as body data. Nothing is charged for the 402 itself, and a call that fails after payment settles nothing.",
+  "type": "string"
+}

Changed4 schema fields changedJul 29, 2026

addedOutput schema / properties / chain

Added value: +{
+  "description": "Chain the token was screened on",
+  "type": "string"
+}

addedOutput schema / properties / priceUsd

Added value: +{
+  "description": "Current USD price, when a liquid pair exists",
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / query

Added value: +{
+  "additionalProperties": {},
+  "description": "The resolved lookup this verdict answers",
+  "type": "object"
+}

addedOutput schema / properties / token

Added value: +{
+  "description": "Contract address that was screened",
+  "type": "string"
+}

Changed3 schema fields changedJul 5, 2026
- addedOutput schema / properties / asOf / description
```
Added value: +"ISO 8601 time the verdict was computed"
```
- addedOutput schema / properties / note / description
```
Added value: +"Human-readable caveat about the verdict, if any"
```
- addedOutput schema / properties / source / description
```
Added value: +"Data source (e.g. GoPlus Security + DexScreener)"
```
AddedJun 22, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint/idempotentHint annotations by disclosing the entire paid-call protocol: the first call returns a 402 challenge with a payloadTemplate, nothing is charged for the 402, payment is forwarded as the PAYMENT-SIGNATURE header, a post-payment failure settles nothing, and the npm package can auto-pay. This is exactly the kind of non-obvious behavior an agent needs.

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?

Front-loads price, purpose, and scope, then handles payment mechanics in a compact sentence. It is dense but every clause carries information; the closing 'Not financial advice' is the only near-disposable element.

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?

An output schema exists, so return shapes need not be detailed, yet the description still summarizes the verdict values (safe|caution|danger) and the payment lifecycle. For a paid, multi-call tool this leaves no ambiguity about how to invoke it successfully.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds process semantics the schema alone does not convey: why `payment` is omitted on the first call and sent on the second, and that it travels as a header rather than body data. The chain/token meaning is left to the well-written schema fields.

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?

Starts with a specific verb+resource ('On-chain safety verdict for any EVM token') and enumerates the exact checks performed (honeypot, buy/sell tax, owner privileges, LP-locked, liquidity). This clearly distinguishes it from siblings like token_metadata, token_holders, token_price and token_report.

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?

Explicitly frames timing ('BEFORE you trade it'), which is actionable guidance. However, it never names a sibling alternative or states when a different tool (e.g. token_report or token_holders) would be preferred, so the routing is implicit rather than explicit.

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

All FiatDock tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.