nwc-mcp

nwc_pay_lightning_address

Resolves a Lightning Address to a bolt11 invoice via LNURL-pay, enforces safety checks (allowlist, budget, confirmation), and returns the payment preimage.

Instructions

Pay a Lightning Address (e.g., alice@getalby.com). Resolves the LNURL-pay endpoint to a bolt11 invoice, then runs the safety pipeline (read-only gate, allowlist check on the LN address, budget cap, optional two-step confirmation). Returns preimage on success.

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": {
      "address": "<address>",
      "amount_sats": "<amount_sats>"
    },
    "name": "nwc_pay_lightning_address"
  }
}

Input Schema

Name	Required	Description
`address`	Yes	The Lightning Address to pay (e.g., alice@getalby.com).
`comment`	No	Optional comment for the recipient. Only sent if the LNURL-pay endpoint advertises comment support (LUD-12); otherwise rejected.
`amount_sats`	Yes	Amount to send in satoshis.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 2, 2026

TDQS

A4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses a significant amount of behavioral detail, including the safety pipeline (read-only gate, allowlist, budget cap, optional two-step confirmation) and the return of the preimage on success. This goes beyond typical descriptions, though it omits potential failure modes or specific permission requirements.

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

Conciseness5/5

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

The description is extremely concise, consisting of exactly two sentences. It front-loads the core action ('Pay a Lightning Address') and then efficiently summarizes the technical flow and safety checks. Every sentence earns its place without redundancy.

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 the tool's complexity (payment operation, no output schema, no annotations), the description is quite complete. It explains the end-to-end process, mentions the safety pipeline, and notes the return value. It also implicitly connects to the sibling nwc_confirm_payment via the two-step confirmation. It lacks explicit error scenarios, but the coverage is strong for a tool of this type.

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 baseline is 3. The description does not add additional meaning beyond what the schema already provides for each parameter; the schema covers address format, comment behavior (LUD-12), and amount constraints. The description's mention of 'budget cap' indirectly relates to amount_sats but not in a parameter-specific way.

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 clearly states the tool's purpose with a specific verb+resource: 'Pay a Lightning Address'. It also distinguishes itself from sibling tools by explicitly mentioning the resolution of LNURL-pay to a bolt11 invoice, which sets it apart from tools like nwc_pay_invoice or nwc_pay_lnurl.

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

Usage Guidelines3/5

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

The description implies usage context by explaining the tool's workflow (resolving an address to an invoice), but it does not explicitly state when to use this tool versus alternatives like nwc_pay_invoice or nwc_pay_lnurl. It provides no exclusions or when-not-to-use guidance.

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

Deploy Server