SatsDNS

Add 1 million queries to a zone (200 sats)

zone_add_queries

Adds 1 million queries to a hosted zone's monthly allowance. 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>"
    },
    "name": "zone_add_queries"
  }
}

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	A zone hosted here.
`cashu`	No	Cashu token (cashuA... or cashuB...) worth at least the price, from an accepted mint (see info). Pays without a previous call.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 28, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Adds substantial context beyond the annotations: the unpaid call returns payment_required with a price, Lightning invoice and Cashu request, every request is validated free before invoicing, and payment must be authorized by the user. It does not mention failure modes such as unknown zones or expired invoices, which is why it is not a 5.

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 core action and price are front-loaded, and the payment flow follows logically in one dense sentence. It is slightly run-on with layered clauses, but no sentence is filler.

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 correctly explains the payment_required response shape and the paid success path, which is the key return-value information. Error handling for an invalid zone or rejected cashu token is not covered, leaving a small gap.

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 coverage is 100%, so l402, cashu and zone are already documented in the schema. The description only adds the procedural detail that the retry must use the same arguments plus l402, which is marginal value over the schema's own wording.

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, resource and quantity with price: adds 1 million queries to a hosted zone's monthly allowance for 200 sats. This clearly distinguishes it from zone_create and zone_status, which do not touch quota.

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?

Explicitly directs the agent to 'use check first' and explains the two payment paths (l402 retry vs cashu) plus the constraint to pay only within what the user allowed. It lacks an explicit statement about when not to use it versus quota-adjacent siblings like renew or account_order, keeping it just below a 5.

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?