FiatDock

Domain intel: registration, DNS, email auth, TLS ($0.0045)

domain_intel

Read-onlyIdempotent

PAID ($0.0045 USDC via x402). Everything about a domain in one call: the registrar, creation and expiry dates, age, status and nameservers from the registry's own RDAP service; live DNS (A, AAAA, MX, NS); email authentication (the SPF record and the DMARC policy); and the TLS certificate port 443 serves — issuer, validity window, days remaining, whether it covers the name and whether a browser would trust it. Accepts a bare domain or a URL. A TLD whose registry runs no RDAP returns registration null with the reason. A non-existent domain is a paid answer (exists:false); a resolver and registry outage is 502, 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	Default
`domain`	No	A domain or a URL (example.com, https://www.example.com/page). Omit the whole body to get the published example (example.com)
`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
`dns`	Yes	Live DNS answers
`tls`	Yes	The certificate port 443 serves — or an error saying why none was read
`note`	Yes	How to read the answer, and its limits
`domain`	Yes	The host examined (lower-cased)
`exists`	Yes	False only when the registry has no record (or, with no RDAP service, DNS says NXDOMAIN)
`sources`	Yes	Where each part came from
`checkedAt`	Yes	ISO time of the check
`defaulted`	No	Present only when the body was empty: which subject the answer is for, and why
`registration`	Yes	The registry's RDAP record, or null
`emailSecurity`	Yes	SPF record and DMARC policy
`registeredDomain`	Yes	The registered name the registry answered for (e.g. example.com for www.example.com), or null
`registrationNote`	Yes	Why registration is null, when it is

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 4, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations (readOnly/openWorld/idempotent) only cover the safety profile; the description goes far beyond by disclosing the x402 payment flow, the 402 challenge, that a 502 outage is not charged, that any answer it cannot produce is >=400 and uncharged, and the null-registration case for RDAP-less TLDs. This is unusually rich behavioral context.

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-loaded with what the tool returns before the payment mechanics, and every sentence carries information. It is a dense single block with no formatting breaks, which slightly hurts scanability but wastes little.

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 paid, multi-facet tool with an output schema already present, the description covers scope, error/payment semantics, and edge cases. An agent has everything needed to invoke it correctly on both the challenge and payment calls.

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 coverage is 100% and both parameters are already fully documented in the schema (including the payment envelope details), so the description mostly restates rather than adds. The "accepts a bare domain or a URL" note is already in the schema, making this a baseline 3.

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 and enumerates the exact facets returned: registrar/dates/status/nameservers from RDAP, live DNS records, SPF/DMARC, and TLS certificate details. This distinguishes it from siblings like email_check, site_contacts, and address_intel at a glance.

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?

"Everything about a domain in one call" clearly frames it as the comprehensive domain tool, and it specifies accepted input forms (bare domain or URL) plus the paid-answer semantics. It gives no explicit when-not or named alternative, so it stops 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.