Skip to main content
Glama
Sign In

SatsDNS

by com.satsdns
OverviewDiscussionsAdmin

Host a DNS zone (500 sats 30d, 5,000 sats 1y)

zone_create

Creates a hosted, DNSSEC-signed zone on our nameservers. First call check (tool zone_create): a new zone gets its own nameserver pair, which must be set at the registrar before the payment step; pass the ns_ticket from that answer. The answer gives the zone token once (keep it: it manages the zone), the nameservers and the DS record. 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": {
      "zone": "<zone>",
      "period": "<period>"
    },
    "name": "zone_create"
  }
}

Input Schema

NameRequiredDescriptionDefault
l402NoLightning 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.
zoneYesThe domain to host, e.g. example.com (a name you registered at any registrar).
cashuNoCashu token (cashuA... or cashuB...) worth at least the price, from an accepted mint (see info). Pays without a previous call.
periodYes30d (30 days) or 1y (365 days). Prices differ: see the tool title.
ns_ticketNoThe ns_ticket from the delegation_missing answer of an earlier check or call (secret, shown once, 48 h): proves you got this zone's nameserver pair.
previous_tokenNoThe old zone token, only when hosting again a zone you removed or let expire (reserved for you for a while).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Goes well beyond the annotations: it discloses that the zone token is shown once and must be kept, that the call returns payment_required with price, Lightning invoice and Cashu request if unpaid, and that every request is validated for free before invoicing. It stops short of stating expiry/renewal behavior or what happens if payment proof is invalid, so not a full 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, but the single dense paragraph packs the check-first rule, registrar step, token-retention warning, and two payment paths into a run of clauses. The '(tool zone_create)' aside is redundant with the tool name and slightly confusing.

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?

With no output schema, the description fully describes what comes back: zone token (shown once), nameservers, DS record, and the payment_required payload shape. For a paid, non-idempotent creation tool this covers everything an agent needs to call it and handle both outcomes.

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 already 100%, so the baseline is 3; the description earns above baseline by explaining the l402 flow contextually ('pay only within what your user allowed, then call again with the same arguments plus l402') and by tying ns_ticket to the registrar-before-payment step. It still does not add format detail beyond the schema for cashu or previous_token.

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?

Opens with a specific verb and resource ('Creates a hosted, DNSSEC-signed zone on our nameservers') and immediately distinguishes itself from the sibling 'check' tool as a prerequisite step. The paid, no-account nature is stated up front so an agent knows what it is triggering.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: 'First call check (tool zone_create)' and 'use check first', plus the two payment alternatives (retry with l402 after payment_required, or pay directly with cashu). The ordering constraint that the nameserver pair must be set at the registrar before payment is spelled out.

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

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