FiatDock

Token safety & rug check ($0.01)

token_safety

Read-onlyIdempotent

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.

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.2/5.0

Behavior4/5

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

Annotations already declare readOnly, openWorld, and idempotent. The description adds the paid x402 flow, the 402 challenge without payment, the automatic payment via fiatdock-mcp npm package, and the caveat that a failed call settles nothing. This is valuable behavioral context beyond the annotations, though no rate limits or auth details are mentioned.

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?

Information-dense but front-loaded with the paid nature and core purpose. Each sentence earns its place: cost, purpose, checks, output, payment behavior, package automation, and disclaimer. Slightly long but not bloated; the structure flows from what → when → how.

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?

Output schema exists, so return-value details are unnecessary. The description covers the full call flow including the two-step payment handshake, the fee, behavior without payment, and what the verdict includes. For a paid read-only screening tool, nothing an agent needs to call it correctly is missing.

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 the schema already documents token, chain, and payment payload. The description reinforces token's purpose (what checks will be run) and payment's role (completing the purchase), but it adds little beyond the schema's own detailed prose. The baseline of 3 applies because the schema does the heavy lifting.

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?

States a specific verb+resource: on-chain safety verdict for any EVM token BEFORE you trade it. Enumerates the exact risk checks (honeypot, buy/sell tax, owner privileges, holder concentration, LP lock, CEX listing, DEX liquidity), which distinguishes it from sibling tools like token_price or token_report without needing to open their schemas.

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 gives the context when to use this tool: BEFORE you trade any EVM token. It implies it is the pre-trade screening gate, and explains the payment flow (402 challenge first, then paid call) so an agent knows the call sequence. It does not explicitly name sibling alternatives or when not to use it, so it falls short of a 5.

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.