FiatDock

ENS & Basename resolver (both ways, with profile records) ($0.0027)

ens_resolve

Read-onlyIdempotent

PAID ($0.0027 USDC via x402). ENS both ways: a name (vitalik.eth, or a Basename like jesse.base.eth) to its address, or an address to its primary name — which the Universal Resolver verifies resolves back — plus the profile records the name's owner published: url, X/Twitter, GitHub, description and the raw avatar record (not fetched). Read from Ethereum mainnet over public RPCs; Basenames resolve through ENS's off-chain lookup, whose gateway URLs are fetched through FiatDock's SSRF guard. ASCII names only (letters, digits, hyphens). A name with no address, or an address with no primary name, answers 404 and is not charged. 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

TableJSON Schema

Name	Required	Description
`name`	No	An ENS name to resolve (vitalik.eth, jesse.base.eth …) — ASCII letters, digits and hyphens
`address`	No	Or an address, to find its primary ENS name (0x + 40 hex)
`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 time of the read
`name`	Yes	The ENS name
`note`	Yes	What the records are, and the limits
`chain`	Yes	Where ENS was read (Ethereum mainnet)
`query`	Yes	What was asked: a name or an address
`address`	Yes	The address it resolves to (checksummed)
`records`	Yes	Profile records the name's owner published (their words, unverified); avatar is the raw record and is not fetched
`defaulted`	No	Present only when the body was empty: which subject the answer is for, and why
`elapsedMs`	Yes	Time taken, in ms
`primaryName`	Yes	The address's own primary (reverse) name, verified to resolve back, or null
`resolvedVia`	Yes	How the name was resolved
`isPrimaryName`	Yes	True when the address's primary name is this name

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations cover read-only/idempotent/open-world, and the description adds substantial context beyond them: paid x402 flow ($0.0027), 402 challenge not charged, failures >=400 not charged, SSRF-guarded gateway fetches, mainnet public RPCs, off-chain Basename lookup, and that the avatar record is returned raw (not fetched).

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?

Dense but front-loaded with purpose and price, and nearly every sentence carries decision-relevant information. It is a single long block that could be better segmented, but there is little filler.

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 values needn't be described; the description nonetheless covers payment mechanics, error/charging semantics, resolution constraints, and data sources. 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it clarifies the dual role of name vs address (either/or resolution), the ASCII constraint, and the full payment parameter lifecycle (omit on first call, send on second, forwarded as header not body).

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 specific verbs and resources: resolving ENS names and Basenames bidirectionally (name→address and address→primary name) plus profile records. No sibling tool does ENS resolution, so the agent can distinguish it immediately.

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?

Explains the two directions of use, the ASCII-only constraint, and the 404/uncharged behavior for non-resolving inputs. It does not name an alternative sibling, but the use context is clear and the payment flow is spelled out.

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.