FiatDock

Token verdict (EVM + Solana) ($0.009)

token_verdict

Read-onlyIdempotent

PAID ($0.009 USDC via x402). Should your agent touch this token? One call returns a 0-100 safety score, a grade (A-F), a verdict (low_risk, medium_risk, high_risk, critical_risk), the reasons that took points off and what speaks for it, the scanner's own flags (identical to token_safety), and the deepest DEX pair's price, liquidity, volume and age. Works for an ERC-20 on base, ethereum, polygon, arbitrum, optimism, bsc or avalanche, and for a Solana mint (send the base58 address; chain is inferred). The scoring rules are published in every answer (method). Send no body to get USDC on Base. Rule-based risk signals, not investment advice. Without payment this returns the 402 challenge; the fiatdock-mcp npm package pays automatically. Any answer the tool cannot produce is >= 400 and is NOT charged.

Input Schema

Name	Required	Description
`chain`	No	Chain. Default: solana for a base58 mint, base for a 0x address
`token`	No	Token address: an ERC-20 contract (0x…) or a Solana mint (base58). Omit the whole body to get USDC on Base
`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

Name	Required	Description
`asOf`	Yes	ISO time of the oldest upstream read this answer used
`name`	Yes	Token name — the deployer's text, clamped
`note`	Yes	What the verdict is and is not
`grade`	Yes	A (>= 90), B (>= 75), C (>= 60), D (>= 40) or F
`risks`	Yes	The scan's risk flags with no trust applied (on EVM exactly as token_safety reports them; on Solana by this tool's rules)
`token`	Yes	The token address read (an EVM address lower-cased; a Solana mint as given)
`market`	Yes	The deepest DEX pair where this token is the base token (DexScreener); null when none
`method`	Yes	The scoring rules, in full
`source`	Yes	Where the data comes from
`symbol`	Yes	Token symbol — the deployer's text, clamped
`holders`	Yes	Holder count and the largest holder's share of supply, when the scanner reports them
`network`	Yes	Chain the token was read on (base, ethereum, …, or solana)
`pageUrl`	Yes	Public page for this token's last paid verdict on fiatdock.com
`reasons`	Yes	Everything that took points off the score, worst first — the score is 100 plus their points, clamped to 0-100
`summary`	Yes	One sentence: the verdict and its main reason
`trusted`	Yes	True when the scanner lists the token as trusted (its trust list / trusted token)
`verdict`	Yes	critical_risk when any critical flag stands; otherwise from the score
`defaulted`	No	Present only when the body was empty: which subject the answer is for, and why
`positives`	Yes	What speaks for the token (trusted listing, deep liquidity, age, holder count)
`safetyScore`	Yes	0-100, higher is safer, by the stated method
`scanVerdict`	Yes	The scan's verdict with no trust applied — safe, caution or danger (on EVM exactly token_safety's)
`issuerControls`	Yes	Issuer control powers reported but not scored, because the token is trusted or an issuer-run token at its canonical address

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 16, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations only cover read-only/open-world/idempotent, and the description adds a large amount of behavior: it is paid ($0.009 USDC via x402), the first call returns a 402 challenge, failures return >= 400 and are NOT charged, a payment that fails settles nothing, and the scoring method is published in every answer. It also discloses the rule-based (non-advice) nature and chain inference. This goes well 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long and dense, but nearly every sentence carries distinct information (price, outputs, chains, payment flow, error behavior). It is front-loaded with the paid/verdict framing, though a few clauses (e.g., restating the token_safety flag identity) could be tightened.

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?

For a complex paid x402 tool, the description covers the charging model, the 402 handshake, the failure/no-charge rule, supported chains, chain inference, and the output shape, with an output schema also present. An agent has everything needed to invoke it correctly, with only sibling-selection guidance left thin.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning: chain is inferred (base58 mint -> solana, 0x -> base), omitting the whole body yields USDC on Base, and the payment param is the x402 payload forwarded as a header rather than body. These clarify call semantics beyond the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description is highly specific about what the tool produces: a 0-100 safety score, an A-F grade, a verdict enum, the point-deduction reasons, scanner flags, and the deepest DEX pair's price/liquidity/volume/age. It names the token_safety sibling to anchor the shared flags, but it never explicitly states how it differs in purpose from token_safety or token_report, so sibling differentiation is only partial.

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

Usage Guidelines3/5

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

It gives rich procedural guidance on the payment two-call flow and the chain default, but no guidance on when to choose this tool over token_safety, token_report, or token_screener. Usage against alternatives is implied rather than stated.

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.