Skip to main content
Glama

Order with your Nostr account (pay check is free; else an invoice in sats)

account_order

Orders a product into your account, paid by its own invoice: Lightning (15 min) or a new on-chain address (orders of 5,000 sats and up). Prices as in info. pay=check runs the free checks only and makes no invoice: use it first. Refused orders make no invoice. New objects need nip98; renewals and extra queries also work with an api_key whose scope covers the object. Pay only within what your user allowed, then poll order_status with the invoice id. Accounts without a paid order are limited (see info, accounts.npub_limits). Called without nip98 it returns signature_required: the exact URL, method and body to sign, the body's sha256 and an unsigned kind 27235 event template (with proof of work for accounts without a paid order). Sign that, then call again with the same arguments plus nip98. Each signed event works once, within 60 s. Secrets that are ours to receive: object tokens, account API keys (jdk_), signed NIP-98 events; never a private key (nsec or 64 hex characters), wallet connection string or seed words. A raw hex key or seed words inside a sentence cannot be caught here.

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": {
      "product": "<product>",
      "pay": "<pay>"
    },
    "name": "account_order"
  }
}

Input Schema

NameRequiredDescriptionDefault
payYescheck: the free checks only, no invoice (do this first); lightning: a BOLT11 invoice (15 min); onchain: a new bitcoin address (orders of 5,000 sats and up, 24 h, confirmations as in the answer); both.
zoneNozone_* and secondary_create: the zone, e.g. example.com.
nip98NoThe signed NIP-98 event (base64 of its JSON) for exactly the request the signature_required answer of the same call named. Sign it with your own Nostr signer (local key, NIP-46 bunker or a signer tool); never send the private key itself, in any form (nsec, hex or seed words).
periodNo30d or 1y; 1m for zone_queries (default).
api_keyNoA scoped account API key (jdk_...) made in the dashboard. It passes through your model context and transcript: treat it like a password. Key model: a key reads (or, with write access, changes) only the objects in its scope, and sees only their invoices; every key reads the account view (limits and counts); a key never orders new objects and never receives a new object's shown-once token.
productYeszone_create, secondary_create, ddns_create (new objects: nip98 only); zone_renew, ddns_renew, zone_queries (1 million queries; api_key or nip98).
hostnameNoddns_*: the hostname label or full name.
primariesNosecondary_create: public IPv4 addresses of your primary servers.
idempotency_keyNoOptional, 1-64 of A-Z a-z 0-9 _ -: repeat an order with the same key (and a fresh signature) to get the same invoice back instead of a second one, e.g. after a lost answer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

The annotations already mark this as a non-read-only, open-world, non-destructive operation, and the description adds substantial context beyond them: invoice lifetimes, signature_required behavior, single-use 60-second signed events, account limits, and secret-handling constraints. It does not contradict the annotations; the idempotency_key caveat is conditional and does not conflict with idempotentHint=false.

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 long but front-loads the core action and payment modes before moving into authorization, polling, and safety details. Given the complexity of the tool, most sentences earn their place, though some secret-handling text overlaps with the nip98 parameter description.

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?

For a complex 9-parameter ordering tool with no output schema, the description covers the full workflow: free checks first, invoice creation, authentication paths, signature_required retry behavior, polling, and account limits. It is complete enough for an agent to invoke the tool correctly without additional context.

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 parameter meanings are already well documented. The description still adds cross-parameter context by tying product types to nip98 versus api_key authorization and emphasizing pay=check as the first step, which helps an agent choose argument values correctly.

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?

The description states a specific verb and resource: it orders a product into the account and creates an invoice via Lightning or on-chain payment. It distinguishes this from sibling tools by naming order_status for polling and info for prices/limits, so an agent can tell when this tool is the right call.

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?

It explicitly says to run pay=check first, that refused orders make no invoice, and that new objects require nip98 while renewals and extra queries can use an api_key. It also directs the agent to poll order_status with the invoice id after paying, giving clear when-to-use and next-step guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources