SatsDNS

Secondary DNS for your zone (500 sats 30d, 5,000 sats 1y)

secondary_create

We serve your zone as secondaries, transferred from your primaries (public IPv4) with a TSIG key that the answer gives once. The same nameserver-pair step as zone_create applies (check first). 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>",
      "primaries": "<primaries>",
      "period": "<period>"
    },
    "name": "secondary_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.
`zone`	Yes	The domain to host, e.g. example.com (a name you registered at any registrar).
`cashu`	No	Cashu token (cashuA... or cashuB...) worth at least the price, from an accepted mint (see info). Pays without a previous call.
`period`	Yes	30d (30 days) or 1y (365 days). Prices differ: see the tool title.
`ns_ticket`	No	The 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.
`primaries`	Yes	Public IPv4 addresses of your primary servers (AXFR source, NOTIFY sender).
`previous_token`	No	The 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.

First observedOct 28, 2026

TDQS

A4.1/5.0

Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: it explains the unpaid payment_required response, Lightning and Cashu payment paths, the one-time TSIG key, and the free pre-invoice check. These details are consistent with the annotations and materially help the agent understand side effects and failure modes.

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?

The description is front-loaded with purpose and then covers payment flow, which is appropriate for a complex paid tool. It is slightly repetitive around 'check first' and 'checked for free before an invoice is made', but no sentence is wholly wasted.

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?

Given a 7-parameter paid mutation with no output schema, the description covers the key invocation flow, payment handling, one-time secrets, and pre-checks well. It does not fully describe the successful return payload, but enough is provided to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all seven parameters in detail. The description reinforces l402/cashu retry usage and primary IPv4 semantics, but adds little parameter meaning beyond what the schema provides; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the operation: serving the user's zone as secondary DNS, transferred from primary servers, with a TSIG key issued once. It references the sibling tool zone_create and the nameserver-pair step, but does not explicitly contrast when to choose secondary_create over zone_create, so sibling differentiation is only partial.

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?

It gives a clear workflow: use check first, and if unpaid, retry with l402 or cashu after payment. It does not explicitly state when-not to use this tool versus zone_create, but the payment and check-first guidance is strong.

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?