Your agent hits "where do I send the money?" One tool call.

MCP gave your agent tools and context. It did not give it an address book. So agents hard-code wallet addresses — strings that can't be rotated, carry no compliance signal, and silently misroute funds the day a recipient changes chains.

This server gives it one. Your agent asks for pay:acme.user and gets back the payment endpoints behind that name, chosen by fixed rules. The name is permanent; the rail behind it can be repointed without breaking a single agent that pays it.

Install

claude mcp add --transport http dnsofmoney https://api.dnsofmoney.com/mcp/rpc

That is the entire install. It is a remote streamable-HTTP MCP server: nothing to download, no npm package, no local process to babysit, no version of ours to keep in sync with yours.

{
  "mcpServers": {
    "dnsofmoney": {
      "type": "http",
      "url": "https://api.dnsofmoney.com/mcp/rpc"
    }
  }
}

claude mcp add --transport http dnsofmoney https://api.dnsofmoney.com/mcp/rpc \
  --header "X-API-Key: YOUR_KEY"

We're listed in the official MCP registry as io.github.sparkmastergrape/dns-of-money, so clients that browse the registry can find and add it without touching a config file.

The tools your agent gets

Every one of them is read-only. Your agent moves the money from its own wallet.

What you see without a key

Install and call it anonymously. There is no signup wall, and paying needs no key: get_payment_requirements returns a payable address and amount to any caller, so an agent can settle against a pay: alias with zero credentials. Anonymous callers can also check name availability and confirm that an alias resolves.

A free API key (no credit card) adds the directory view from resolve_alias: the endpoint set behind a name, which rails and currencies it accepts, priorities and fallbacks. Raw destination addresses and internal routing metadata stay at the highest tier.

That line is deliberate. Paying requires no permission. Reading the full address book behind a name requires an identified caller.

curl -s -X POST https://api.dnsofmoney.com/api/v1/access-requests \
  -H 'Content-Type: application/json' \
  -d '{"name":"Your Name","email":"you@example.com","use_case":"agent payments"}'

Free, manually reviewed, typically within 24 hours.

What happens to the money

Your agent signs and submits its own payment on its own rail. The server resolves the name, returns the endpoints, and after the transaction lands it verifies the ledger record and writes a settlement entry. On Base and Solana the x402 facilitator pays the network fee, so the agent holds no gas token; an external agent proved that on Solana on 2026-08-01, spending 0.01 USDC and zero SOL (TX 3vGQmSoZ…).

No model picks a rail. Fixed rules produce the same endpoint from the same inputs every time, which is the property that makes a payment address worth trusting. The intelligence lives in your agent.

Screen before you pay

Before an agent pays a counterparty it has never seen, one paid call (GET /api/v1/x402/screen/{target}, 0.01 USDC, price set server-side) returns an OFAC and resolution attestation about that target, which can be a pay: alias or a raw address on any chain. The attestation is a W3C Verifiable Credential signed by did:web:dnsofmoney.com with eddsa-jcs-2022. The a2a-protocol-core package (PyPI and npm, 0.3.0) verifies it in your agent's own process, so the proof chain ends with you rather than at TLS. An unsigned attestation fails verification by design.

The flow, end to end

1. Your agent decides it needs to pay, and has a pay: name.
2. It calls resolve_alias and gets ranked endpoints back.
3. It picks a rail on your policy — amount, speed, asset, whatever you decide.
4. It signs and submits the payment with its own wallet or x402 tooling.
5. It keeps the signed resolve, settlement and screen attestations for the audit trail.

No addresses in your prompts. No addresses in your source. Just a name that keeps working.

DNS://Money resolves names and records settlement; it does not take deposits, hold customer funds, or transmit money, and nothing here is financial or legal advice. Tool availability reflects the live production server; some tools are feature-flagged and appear only when their feature is enabled.