SatsDNS

Dynamic DNS hostname under dynkite.com (200 sats 30d, 2,000 sats 1y)

hostname_create

Creates a dynamic hostname such as myhome.dynkite.com. The answer gives the hostname token once (keep it: hostname_update and routers use it). Nothing renews it automatically: give npub to get Nostr reminders before it expires. From 2026-11-10, a create for a hostname that is already taken (bought more than a day ago) RENEWS it instead, like the renew tool: payment_required says so first, and it gives no hostname and no token. Paid, no account. Without payment the call returns payment_required with the price, a Lightning invoice and a Cashu payment request; pay only within what your user allowed, then call again with the same arguments plus l402=':', or call with cashu=''. Every request is checked for free before an invoice is made; use check first.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "hostname": "<hostname>",
      "period": "<period>"
    },
    "name": "hostname_create"
  }
}

Input Schema

Name	Required	Description
`l402`	No	Lightning payment proof for a retry: '<macaroon>:<preimage>', where macaroon comes from the payment_required answer of the previous call and preimage is the 64-hex proof your wallet returns after paying its invoice. Use it with the same tool and arguments.
`npub`	No	Optional: a Nostr public key (npub1... or 64 hex) that gets direct-message reminders before the hostname expires, when grace starts and before removal. Reminders only: the key gets no control; managing the hostname still needs its token.
`cashu`	No	Cashu token (cashuA... or cashuB...) worth at least the price, from an accepted mint (see info). Pays without a previous call.
`token`	No	Only if you already hold this hostname's token (jdh_...): a create for your own hostname then answers hostname_owned with its expiry and how to renew, instead of hostname_taken (from 2026-11-10: a renewal invoice that says the hostname is already yours).
`period`	Yes	30d (30 days) or 1y (365 days). Prices differ: see the tool title.
`hostname`	Yes	A label such as myhome (becomes myhome.dynkite.com), or the full name.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 8, 2026

changedInput schema / properties / token / description

Previous value: -"Only if you already hold this hostname's token (jdh_...): a create for your own hostname then answers hostname_owned with its expiry and how to renew, instead of hostname_taken."New value: +"Only if you already hold this hostname's token (jdh_...): a create for your own hostname then answers hostname_owned with its expiry and how to renew, instead of hostname_taken (from 2026-11-10: a renewal invoice that says the hostname is already yours)."

Changed2 schema fields changedNov 7, 2026

addedInput schema / properties / npub

Added value: +{
+  "description": "Optional: a Nostr public key (npub1... or 64 hex) that gets direct-message reminders before the hostname expires, when grace starts and before removal. Reminders only: the key gets no control; managing the hostname still needs its token.",
+  "type": "string"
+}

addedInput schema / properties / token

Added value: +{
+  "description": "Only if you already hold this hostname's token (jdh_...): a create for your own hostname then answers hostname_owned with its expiry and how to renew, instead of hostname_taken.",
+  "type": "string"
+}

First observedOct 28, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only declare it as a non-readonly, open-world, non-destructive, non-idempotent write. The description adds substantial behavior the agent cannot get elsewhere: payment is required with no account, the invoice/Cashu flow, a free pre-check before invoicing, the token being returned exactly once, no automatic renewal, and the surprising 2026-11-10 rule where a create on a taken hostname silently becomes a renewal.

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?

Purpose and the critical 'keep the token' warning are front-loaded, and every segment is informative. It is dense and slightly run-on, and the payment mechanics (l402/cashu) are restated from the schema descriptions, so it is not maximally tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of describing responses and does so: the hostname token answer, payment_required with price/invoice/Cashu request, and hostname_owned/hostname_taken outcomes. Pricing is only given in the title and only partially linked to the period parameter, which is a minor completeness gap for a paid, state-mutating tool.

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 the baseline is 3 and the schema already documents l402, cashu, npub, token, period and hostname. The description still adds value by binding the parameters into a workflow – same arguments on retry, npub for reminders only (not control), token needed for updates – which is meaning beyond the field-level text.

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 and resource ('Creates a dynamic hostname such as myhome.dynkite.com') and immediately ties it to a concrete example. It also distinguishes itself from siblings by naming renew (the renewal tool) and check (the free pre-check) and by explaining the future overlap with renewal behavior.

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?

Gives explicit operational sequencing: 'use check first', then handle payment_required by paying and retrying with l402 or supplying cashu. It also disambiguates the renew path that takes effect from 2026-11-10. It stops short of stating when to prefer hostname_update or the standalone renew tool instead, leaving some sibling selection to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All SatsDNS 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.

Resources

Need Help?