Namefi MCP Server: Domain Tools for AI Agents

Every AI agent that connects to the Namefi MCP server sees the same list of callable tools — one per operation the API defines, covering search, registration, DNS, domain-level configuration, outbound lead finding, and payment. This page is the catalog: every tool, what it does, what auth it needs, and three worked examples combining several tools into an actual workflow.

If you haven't connected an agent to Namefi yet, start with How to Register a Domain with Your AI Agent on Namefi for per-client setup, or Buy a Domain with Claude: Namefi MCP Step-by-Step Guide for a full transcript. This page assumes the connection already exists.

What the Namefi MCP server is

Namefi runs a single MCP server for its entire API, at https://api.namefi.io/mcp, over the Streamable HTTP transport. Instead of an agent hand-rolling REST calls from documentation pasted into a chat, it connects once and receives a typed tool for every operation the API defines — generated straight from Namefi's own OpenAPI 3 specification at api.namefi.io/v-next/openapi/doc.json, so the MCP catalog and the REST API can't drift apart from each other.

A machine-readable discovery descriptor at namefi.io/.well-known/mcp/servers.json lets an agent find the server without a human pasting a URL into a config file by hand: it names the server namefi-api, reports streamable-http transport, and declares apiKey/x-api-key as the connection auth. Namefi, an ICANN-accredited registrar, also publishes the same operations as plain HTTPS endpoints at namefi.io/llms.txt, for agents and scripts that don't speak MCP.

The complete capability catalog

Below is every operation the API defines as of this writing, grouped the way Namefi's own reference groups them. The Operation column is the operationId from the OpenAPI spec — the name an MCP client's tool list is built from. The Auth column shows the simplest path (an API key covers nearly everything); the full auth model, including the alternatives to an API key, is in the next section.

Search & discovery

Registration & orders

Registration is asynchronous — registerDomain returns an order id immediately, and the agent polls getOrder until it settles. The Claude walkthrough and multi-agent setup guide both show this pattern in full transcript form.

DNS record management

Full CRUD, one record at a time or batched, plus a read that needs no authentication at all:

Supported record types: A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, SRV, CAA, DS, TLSA, SSHFP, HTTPS, SVCB, NAPTR, SPF. Two formatting rules trip up most first attempts: zoneName must not have a trailing dot, while rdata values for CNAME, MX, and NS records must.

Domain-level toggles

These flip a whole feature on or off, distinct from a single DNS record:

Note that DNSSEC is not one of these toggles — it's set at registration time, one of the domainSetupOptions fields on registerDomain above, not a separate endpoint an agent calls after the fact.

Domain configuration

When auto-renewal is on, the domain renews automatically before expiration using the payment methods on the owner wallet — a standing authorization worth deciding deliberately per domain, not leaving on by default across a whole portfolio.

Outbound lead finding

The newest surface, turning owned domains into a sales pipeline instead of a static asset list:

The response excludes internal ranking mechanics — score, model details, suppressed-lead status — so an agent summarizing results for a human only sees the public rationale, the contact found, and whether a draft exists.

Payments & account

That covers every operation in scope for search, registration, DNS, domain configuration, outbound, and payment — each reachable as an MCP tool through the single server connection, or as a plain HTTPS call for agents that don't speak MCP. (Namefi's API also exposes a few account-management and EIP-712/SIWE helper operations outside this list; the full set is always current in the OpenAPI spec linked in Sources below.)

The auth model: three paths in, one wallet behind all of them

Every write operation above checks the same thing — does the caller control the wallet that owns, or will own, the domain — by one of three paths. Which applies depends on the operation, not a single account-level setting.

API key (x-api-key). The simplest option, and the one every worked example in this cluster uses. Generate one at namefi.io/api-key; it works for every operation above, including DNS writes, parking, and registration, because the key inherits the permissions of the wallet that generated it — pass it as a plain HTTP header, no SDK required.

EIP-712 typed-data signature. For programmatic use without a stored key, sign each request with an Ethereum wallet: headers x-namefi-signer, x-namefi-signature, and x-namefi-eip712-type wrap the payload in an envelope with a timestamp and single-use nonce that expires after 300 seconds — the mode operations like toggleDomainParking, createDnsRecord, and registerDomain require without an API key. The domain and type definitions come from live endpoints (GET /v-next/eip712/domain, /eip712/types) rather than a hardcoded constant, since Namefi's docs note they can change. Smart-contract wallets can't sign directly, so an approved externally-owned account signs on the contract's behalf, with x-namefi-erc1271-account or x-namefi-eip7702-account naming which contract is authorizing the request.

SIWE (Sign-In with Ethereum). A session token (x-namefi-siwe-token) for protected reads that don't need a fresh signature per call, like listing owned domains or orders — fetch a nonce, get the message to sign, sign it with personal_sign, verify it, then reuse the token.

A handful of operations need no authentication — checkAvailability, getSuggestions, getDnsRecords, isDomainParked, and the EIP-712 metadata endpoints — because they're read-only and expose nothing a domain's public DNS wouldn't already show a browser.

Layered on top is payment. registerDomainX402 settles a purchase via the x402 protocol: the buyer's wallet signs an EIP-3009 transferWithAuthorization for a stablecoin like USDC, no Namefi account involved. registerDomainMPP reaches the same outcome via a signed challenge-response instead. Both let an agent skip account creation and pay per transaction — Pay for Domains with a Crypto Wallet: No Account Needed covers that path end to end.

Tokenization runs through the catalog, not beside it

registerDomain mints the domain as an NFT — an ERC-721 token, the standard interface most marketplaces and wallets already read — on Base by default, to the wallet tied to the caller's API key. nftReceivingWallet redirects that to a different wallet or chain at registration time, and everything downstream — DNS writes, parking, auto-renewal, outbound lead-finding — checks that same on-chain ownership record rather than a separate account database. A tokenized domain traded on a marketplace like OpenSea carries its DNS control and ERC-721 ownership as one object, not two systems to keep in sync by hand.

Three agents, three ways to use the same toolset

A builder registers a domain and ships DNS in one conversation. checkAvailability confirms the name is free, registerDomain submits it with domainSetupOptions set for autoRenew and dnssec, and once the order reaches SUCCEEDED, batchCreateDnsRecords writes the CNAME and TXT records a deployment platform's verification step is waiting on. The Namefi MCP quickstart for coding agents walks through this sequence inside an editor.

A domain trader manages a portfolio. getUserDomains pulls current holdings, checkBulkAvailability screens new candidates in one call, and registerDomain picks up the ones worth acquiring. For names being resold, toggleDomainParking puts up a landing page and isDomainParked confirms it's live; across the portfolio, getAutoRenew and toggleAutoRenew decide which names are worth a standing renewal authorization and which are speculative enough to let lapse.

A business runs outbound lead-finding on names it already owns. getUserDomains identifies an unused domain, startOutboundRun kicks off research, and getOutboundRun polls until it reaches SUCCEEDED. listOutboundLeads returns ranked businesses whose profile suggests they'd want that name, and prepareOutboundOutreach drafts an email per lead — generated once, then returned free on repeat calls.

Before an agent runs any of this unattended

Namefi's own outbound documentation flags four operations as consequential — registerDomain, registerWithRecords, startOutboundRun, prepareOutboundOutreach — because each spends balance or takes an externally visible action. Read-only tools like checkAvailability carry no risk to run autonomously; anything that writes an order, a DNS record on a live domain, or an outreach draft is worth a confirmation step. What Is an Agent-Native Domain Registrar? has a fuller checklist for evaluating any registrar's agent-facing surface this way.

Keeping this catalog current

This table mirrors Namefi's live OpenAPI specification as of the publish date above, not a fixed roadmap — new operations land in namefi.io/llms.txt and namefi.io/llms-full.txt before they land in any blog post's table.

Frequently Asked Questions

Do I need an API key just to check whether a name is available?

No. checkAvailability, checkBulkAvailability, and getSuggestions require no authentication, so they work against a freshly connected agent before funding anything.

Can an agent use this whole catalog without me ever holding a Namefi API key?

Yes. registerDomainX402 and registerDomainMPP both settle a registration through a wallet signature with no Namefi account, and EIP-712 signing covers the rest of the write operations directly from a wallet.

Is a domain automatically tokenized when I register it through any of these paths?

Yes, by default, across every registration path. If nftReceivingWallet isn't specified, the domain registers as an ERC-721 NFT to the wallet tied to the caller's API key, on Base.

Which operations should a human confirm before an autonomous agent runs them?

At minimum, the four Namefi's docs mark as consequential — registerDomain, registerWithRecords, startOutboundRun, prepareOutboundOutreach — plus any DNS write on a domain already serving live traffic.

Connect your agent to the full catalog

Every tool above is live behind one connection: https://api.namefi.io/mcp. If you haven't set that up yet, How to Register a Domain with Your AI Agent on Namefi covers exact configuration for six different clients, and llms.txt for Domains explains the discovery layer underneath it.

Generate a Namefi API key and point your agent at the server — the tools above are what it will find waiting.

Sources and further reading

• Namefi — namefi.io/llms.txt (MCP server URL, transport, authentication, core operation reference — primary source for this catalog)
• Namefi — namefi.io/llms-full.txt (single-file reference inlining Web3 payments and outbound lead-finding)
• Namefi — namefi.io/web3/llms.txt (x402, MPP, EIP-712, and SIWE flows in detail)
• Namefi — namefi.io/.well-known/mcp/servers.json (MCP discovery descriptor: server name, URL, transport, auth type)
• Namefi — api.namefi.io/v-next/openapi/doc.json (machine-readable OpenAPI 3 spec — source of every operationId and endpoint in the capability catalog above)
• Namefi — docs.namefi.io: Authentication (API key, EIP-712, and SIWE auth modes; per-operation auth requirements; ERC-1271/EIP-7702 delegation)
• Namefi — docs.namefi.io: Register a domain (registration request fields, polling flow, order status values)
• Namefi — docs.namefi.io: Managing your balance (NFSC balance and faucet endpoints)
• Model Context Protocol — What is the Model Context Protocol? (protocol overview)
• llmstxt.org — The /llms.txt file (specification and rationale for the discovery convention Namefi's file follows)
• x402.org — x402 protocol (HTTP 402-based stablecoin payment standard underlying registerDomainX402)
• Ethereum Improvement Proposals — ERC-721: Non-Fungible Token Standard (the token standard Namefi's domain NFTs implement)