Skip to main content
Glama
Sign In

Lightning Wallet

by io.github.lightningfaucet
OverviewDiscussionsAdmin

nostr_zap

Send a Nostr zap (NIP-57 Lightning payment with optional Nostr event). If the recipient supports NIP-57, a proper zap receipt is created. Otherwise falls back to a regular Lightning address payment. REQUIRES AGENT KEY with Nostr identity set. Paid as a Lightning-address payment: platform fee 1% of the amount, rounded down, minimum 1 sat, reported as platform_fee_sats.

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": "nostr_zap"
  }
}

Input Schema

NameRequiredDescriptionDefault
relaysNoNostr relay URLs for zap receipt
addressYesLightning address to zap (user@domain.com)
contentNoOptional zap comment/message
event_idNoNostr event ID to attach zap to (hex format)
amount_satsYesAmount in satoshis to zap
recipient_pubkeyNoNostr hex pubkey of recipient (for NIP-57 zap receipt)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the prerequisite identity requirement, that a zap receipt may or may not be created depending on recipient NIP-57 support, and the exact fee model (1% rounded down, min 1 sat, reported as platform_fee_sats). It still omits failure modes (e.g., insufficient balance, invalid lightning address) and irreversibility of the payment.

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?

Four tight sentences, front-loaded with the action, then the branch behavior, then the prerequisite, then the cost. No filler or repeated schema content.

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?

Six parameters with no annotations and no output schema, and the description covers prerequisites, fallback semantics and fee reporting. It leaves return-shape details (beyond platform_fee_sats) and error behavior unstated, a modest gap for a payment tool.

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 baseline is 3, but the description adds real meaning the schema does not: relays, recipient_pubkey and event_id are only meaningful on the NIP-57 path, and event_id is described as an optional attachment rather than a target. That conditional-parameter relationship is absent from the schema.

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?

Specific verb and resource ('Send a Nostr zap (NIP-57 Lightning payment with optional Nostr event)') with the fallback path spelled out. An agent can distinguish this from pay_lightning_address and keysend from the description alone, since those siblings have no NIP-57 receipt semantics.

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?

States the hard prerequisite ('REQUIRES AGENT KEY with Nostr identity set') and the conditional branch (NIP-57 vs. plain Lightning-address fallback). It does not explicitly tell the agent when to prefer pay_lightning_address or keysend over this tool, which keeps it 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 Lightning Wallet 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