Skip to main content
Glama
Sign In

loop-mcp

by com.loopxxi
OverviewDiscussionsAdmin

lightning_address_resolve

Read-only

Resolve a Lightning Address (user@domain.com) to a payable BOLT11 invoice for a given amount. Handles the full LNURL-pay protocol internally. Returns the invoice plus min/max sendable amounts for validation.

Input Schema

NameRequiredDescriptionDefault
addressYesLightning Address in user@domain.com format.
l402_proofNoL402 payment proof "<macaroon>:<preimage>". Omit on the first call; an unpaid call returns a 0 sat Lightning invoice and the macaroon. Pay the invoice, then repeat the call with this argument set.
amount_satsYesAmount you want to send, in satoshis. At most 100000000 (1 BTC).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / l402_proof / description
      Previous value: -"L402 payment proof \"<macaroon>:<preimage>\". Omit on the first call; an unpaid call returns a 10 sat Lightning invoice and the macaroon. Pay the invoice, then repeat the call with this argument set."New value: +"L402 payment proof \"<macaroon>:<preimage>\". Omit on the first call; an unpaid call returns a 0 sat Lightning invoice and the macaroon. Pay the invoice, then repeat the call with this argument set."
  2. Changed3 schema fields changed
    • changedInput schema / properties / amount_sats / description
      Previous value: -"Amount you want to send, in satoshis."New value: +"Amount you want to send, in satoshis. At most 100000000 (1 BTC)."
    • addedInput schema / properties / amount_sats / maximum
      Added value: +100000000
    • addedInput schema / properties / l402_proof
      Added value: +{
+  "description": "L402 payment proof \"<macaroon>:<preimage>\". Omit on the first call; an unpaid call returns a 10 sat Lightning invoice and the macaroon. Pay the invoice, then repeat the call with this argument set.",
+  "type": "string"
+}
  3. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety and external-network reach are covered. The description adds that the LNURL-pay protocol is handled internally and that min/max sendable amounts come back for validation, which is genuine extra context. However, it omits the L402 gating behavior (the first call returns a 0-sat invoice and macaroon), leaving that disclosure entirely to the schema.

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?

Three short sentences, front-loaded with the core verb and resource, then the protocol behavior, then the return payload. Each sentence carries distinct information with no filler or restated title.

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 usefully states what comes back (invoice plus min/max amounts), and the annotations cover the safety profile. It is a simple two-required-parameter lookup, so little more is needed; the main gap is error behavior for malformed addresses or unreachable domains.

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: address format, the 1–100,000,000 sat bounds, and the l402_proof flow are all fully documented in the schema. The description only reinforces that amount is what the caller wants to send and that min/max should be checked against it, adding little beyond the structured fields.

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 gives a specific verb and resource: 'Resolve a Lightning Address (user@domain.com) to a payable BOLT11 invoice', including the exact input format and output type. No sibling tool in the list overlaps with Lightning payments, so there is nothing to disambiguate against, which keeps this just short of a 5.

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?

Usage is implied by the phrasing 'for a given amount' — an agent infers this is the tool for turning a Lightning Address into a payable invoice. There is no explicit when-to-use or when-not guidance, no prerequisites, and no mention of what to do when the address is invalid or the domain is unreachable.

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

All loop-mcp 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