Namefi MCP Server: Domain Tools for AI Agents

An AI agent that connects to the Namefi MCP server receives callable tools generated from the server's supported /v-next API surface, covering search, registration, DNS, domain configuration, account operations, and outbound lead finding. The x402 and MPP payment flows use separate HTTP endpoints; they are not MCP tools. This page catalogs the documented MCP surface, explains authentication, and gives three workflows.

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 Streamable HTTP MCP server at https://api.namefi.io/mcp. Instead of an agent hand-rolling REST calls from documentation pasted into chat, it connects and receives typed tools for the supported /v-next operations generated from Namefi's OpenAPI 3 specification at api.namefi.io/v-next/openapi/doc.json. Generation reduces manual drift, but the live tool list, OpenAPI document, discovery descriptor, and blog snapshot can still change at different times; inspect tools/list for the connection you are actually using.

A machine-readable discovery descriptor at namefi.io/.well-known/mcp/servers.json names the server namefi-api, reports streamable-http transport, and documents both x-api-key and OAuth 2.1 authorization-code authentication with PKCE, protected-resource discovery, refresh tokens, device flow, and dynamic client registration. Namefi, an ICANN-accredited registrar, also publishes plain HTTPS endpoints at namefi.io/llms.txt for agents and scripts that do not speak MCP. That file explicitly identifies /x402/... and /mpp/... as separate HTTP payment endpoints, not MCP tools.

The complete capability catalog

Below is a dated snapshot of the documented /v-next operation groups. The Operation column is the OpenAPI operationId from which an MCP tool name is built. The Auth column shows the REST-level API-key path; an MCP client can instead authenticate its session with an OAuth bearer token. Rows labeled public REST do not imply an anonymous MCP connection: an unauthenticated initialize request returned 401 Unauthorized when verified on July 14, 2026.

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. The REST read is documented as public, while the live MCP endpoint currently requires the session itself to authenticate:

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.

Account tools available through /v-next

The sections above are a dated snapshot of the documented /v-next operations that the MCP server can expose. The live tools/list response is authoritative for a connected client; the OpenAPI document linked below is authoritative for plain REST operations and may include helpers outside this editorial catalog.

Outside MCP: x402 and MPP payment endpoints

Namefi also publishes wallet-paid registration flows as plain HTTP endpoints. They can be called by an agent with a general HTTP client, but they do not appear merely because the agent connected to the Namefi MCP server.

Authentication: MCP connection auth and REST request auth are different layers

An MCP client must first authenticate the server connection. The current discovery descriptor advertises OAuth 2.1 bearer tokens, with authorization code plus PKCE, protected-resource and authorization-server metadata, refresh tokens, device flow, and dynamic client registration. Compatible clients can therefore connect with the MCP URL and complete an OAuth flow without storing a Namefi API key in their configuration.

API key (x-api-key). For explicit header-based or automated setups, generate a key at namefi.io/api-key and pass it as an HTTP header. A key is sensitive: keep it out of committed MCP configuration and scope its use to the permissions Namefi grants it.

The descriptor also says certain read-only tools need no authentication. However, an unauthenticated MCP initialize request returned 401 Unauthorized when verified on July 14, 2026. Because initialization comes before any tool call, treat the live MCP connection as authentication-required until the implementation and descriptor agree.

For direct REST calls, Namefi documents additional request-level authentication modes. These are not a promise that an MCP client will automatically obtain a wallet signature for every tool call:

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 REST reads that do not need a fresh signature per call, such as listing owned domains or orders — fetch a nonce, get the message to sign, sign it with personal_sign, verify it, then reuse the token.

The x402 and MPP flows add payment authorization to their separate HTTP endpoints; they are not alternate authentication methods for an unauthenticated MCP connection. Pay for Domains with a Crypto Wallet: No Account Needed covers those HTTP flows end to end.

Tokenization runs through the catalog, not beside it

registerDomain can mint the domain as an NFT — an ERC-721 token, the standard interface many wallets and marketplaces can display — on Namefi's supported chain to the designated receiving wallet. nftReceivingWallet selects that wallet; it does not select an arbitrary chain. The token represents on-chain control within Namefi's system, while registrar, registry, ICANN policy, Namefi's agreements, and court orders remain separate layers. Marketplace display and trading support also depend on the platform and collection configuration.

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. A read-only call such as checkAvailability does not spend funds, but the current MCP session still needs authentication and its output can influence later actions. Anything that writes an order, changes DNS on a live domain, or creates externally directed outreach deserves an explicit 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?

Not necessarily. A compatible MCP client can authenticate with OAuth instead of a static API key. The underlying availability REST operations are documented as public, but the live MCP endpoint required authentication to initialize when checked on July 14, 2026. Availability checks do not require funding.

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

It can use OAuth for the MCP connection, without storing a Namefi API key. For direct REST integration, EIP-712 and SIWE cover supported request types. The x402 and MPP registration flows are separate HTTP endpoints, not MCP tools or substitutes for MCP connection authentication, so inspect the current documentation for the particular operation you need.

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

For the documented /v-next registerDomain flow, Namefi mints the domain token to the designated receiving wallet on its supported chain. This catalog does not establish identical defaults for every separate registration and payment path, so inspect the current documentation for the path you are calling rather than assuming an API-key wallet or a particular chain.

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 current catalog

The MCP tools generated from the supported /v-next surface are available through https://api.namefi.io/mcp; x402 and MPP remain separate HTTP endpoints. Because the catalog can change, inspect the connected server's tools/list rather than treating this article as a permanent schema. If you have not connected yet, How to Register a Domain with Your AI Agent on Namefi covers configuration for six clients, and llms.txt for Domains explains the discovery layer underneath it.

Connect with OAuth in a compatible client, or generate a Namefi API key for an explicit header-based setup, then inspect the live tool list.

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, OAuth metadata, API-key authentication, and the read-only auth claim that differed from live initialize behavior on July 14, 2026)
• 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 used by Namefi's separate /x402/... endpoints)
• Ethereum Improvement Proposals — ERC-721: Non-Fungible Token Standard (the token standard Namefi's domain NFTs implement)