Skip to main content
Glama
getAlby

Alby Bitcoin Payments MCP Server

Official
by getAlby
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Alby Bitcoin Payments MCP Server

NEW: also checkout Alby CLI for agents that don't support MCP.

Connect a bitcoin lightning wallet to your LLM using Nostr Wallet Connect (NWC).

This MCP server uses the official MCP TypeScript SDK

This MCP server has knowledge of NWC, LNURL and L402 using Alby SDK and Alby Lightning Tools.

Take a look at Awesome AI Bitcoin for places where you can use the Alby MCP.

Quick Start

In case you get stuck, see troubleshooting section below.

Use the Alby-Hosted MCP Server

If your agent supports remote MCP servers - SSE (e.g. N8N) or HTTP Streamable transports, you can connect to Alby's MCP server.

  • SSE: https://mcp.getalby.com/sse

  • HTTP Streamable: https://mcp.getalby.com/mcp

Authentication

Both require providing an NWC connection secret as authentication, either as Bearer authentication (preferred) or via the nwc query parameter.

Bearer Auth

Example: Authorization: Bearer nostr+walletconnect://...

If your agent UI supports bearer auth, just paste the connection secret into the bearer auth field.

Query Parameter

If your agent doesn't support bearer auth, you can pass the NWC connection secret as a query parameter.

Example: https://mcp.getalby.com/sse?nwc=ENCODED_CONNECTION_SECRET or https://mcp.getalby.com/mcp?nwc=ENCODED_CONNECTION_SECRET

To get ENCODED_CONNECTION_SECRET, open browser devtools (right click -> inspect) and enter this in the console, with your own NWC connection secret set:

encodeURIComponent("nostr+walletconnect://...");

In case there is a message asking for confirmation for pasting, follow the instructions, and then enter the above command again.

Once the command has run, copy the output and replace ENCODED_CONNECTION_SECRET. It will look like this: nostr%2Bwalletconnect%3A%2F%2F...

Add to Claude Web or Claude Desktop

Use the remote Alby MCP server

Currently, at least a Claude Pro subscription is required to be able to connect to remote MCP servers.

  1. Go to Settings -> Connectors

  2. Click on "Add custom connector"

  3. Call it alby

  4. What is the endpoint URI: https://mcp.getalby.com/mcp?nwc=ENCODED_NWC_URL (see above for instructions)

Client-side

Add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "nwc": {
      "command": "npx",
      "args": ["-y", "@getalby/mcp"],
      "env": {
        "NWC_CONNECTION_STRING": "YOUR NWC CONNECTION STRING HERE"
      }
    }
  }
}

Add to Goose Desktop

  1. Open Goose Desktop

  2. Go To Settings -> Advanced Settings

  3. Click on "Add custom Extension"

  4. Call it alby, and change the type to HTTP Streamable

  5. What is the SSE endpoint URI: https://mcp.getalby.com/mcp

  6. Timeout: 30

  7. Description: no

  8. environment variables: no

Add to Goose CLI

Use the Alby MCP server

  1. Type goose configure

  2. Add extension -> Remote Extension (HTTP Streamable)

  3. Call it alby

  4. What is the HTTP Streamable endpoint URI: https://mcp.getalby.com/mcp

  5. Timeout: 30

  6. Description: no

  7. environment variables: no

  8. add custom headers: yes

  9. header name: Authorization

  10. header value: Bearer nostr+walletconnect://... (replace with your connection secret)

Client-side

  1. Type goose configure

  2. Add extension -> Command Line Extension

  3. Call it alby

  4. What command should be run: npx -y @getalby/mcp

  5. Timeout: 30

  6. Description: no

  7. environment variables: yes

  8. environment variable name: NWC_CONNECTION_STRING

  9. environment variable value: nostr+walletconnect://... (your NWC connection secret here)

Add to Cline

Copy the below and paste it into a cline prompt. It should prompt you to update the connection string.

Add the following to my MCP servers list:

"nwc": {
  "command": "npx",
  "args": ["-y", "@getalby/mcp"],
  "env": {
    "NWC_CONNECTION_STRING": "nostr+walletconnect://..."
  },
  "disabled": false,
  "autoApprove": []
}

Add to Claude Code

Use the Alby MCP server

claude mcp add --transport http alby https://mcp.getalby.com/mcp --header "Authorization: Bearer nostr+walletconnect://..."

Add to N8N via SSE

You can use the native N8N MCP Client tool connected to an AI agent. Enter your SSE endpoint, set authentication to "Bearer" and paste your NWC connection secret.

Tested with OpenRouter + anthropic/claude-3.7-sonnet

See the N8N workflow for a simple example

Add to N8N via STDIO (Community Node)

Currently this MCP server only works via command line (STDIO).

You can install the n8n-nodes-mcp community node and run n8n with tools enabled e.g.

N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE=true npx n8n

Create a blank workflow and add an AI agent node. Configure your LLM model and add a new tool "MCP Client" (which will have a cube next to it showing it's a community node).

Configure the MCP Client by adding a credential with Command Line (STDIO) selected.

command: npx arguments: -y @getalby/mcp environments NWC_CONNECTION_STRING=nostr+walletconnect://your_key_here (create the whole line in a text editor and paste it in, since the password field cannot be switched to plaintext)

See the N8N paid chat workflow for a full example

Add to Windsurf

Use the remote Alby MCP server

  1. Download and open your Windsurf Editor

  2. Click on "Windsurf - Settings" in the toolbar at the bottom -> "Advanced Settings" -> "Cascade" -> Plugins (MCP Servers): Click on "Manage plugins" -> "View raw config" -> you'll see your "mcp_config.json"

  3. Paste this to your mcp_config.json:

{
  "mcpServers": {
    "alby": {
      "serverUrl": "https://mcp.getalby.com/sse?nwc=ENCODED_NWC_URL"
    }
  }
}

  1. Replace "ENCODED_NWC_URL" as descripted above. Click "Save" and restart the Windsurf editor.

Related MCP server: Alby Bitcoin Payments MCP Server

Modes

STDIO

By default NWC MCP Server runs locally in STDIO mode.

HTTP

You can set the following environment variable: MODE=HTTP which will enable Streamable HTTP (http://localhost:3000/mcp) and SSE (http://localhost:3000/sse Note: SSE is deprecated).

HTTP requires bearer authorization, where the token is a wallet's NWC connection secret. See the authentication section further above in the README.

From Source

Prerequisites

  • Node.js 20+

  • Yarn

  • A connection string from a lightning wallet that supports NWC

Installation

yarn install

Building

yarn build

Add your NWC connection

Copy .env.example to .env and update your connection string

Inspect the tools (use/test without an LLM)

yarn inspect

Supported Tools

See the tools directory

Troubleshooting

Model Usage

Make sure you use a decent model (e.g. Claude Sonnet 3.7) otherwise the MCP server will not work.

Failure to connect to wallet, secret missing

Make sure you copied the entire NWC connection secret, without spaces

Contact Alby Support

Visit support.getalby.com and we're happy to help you get the MCP server working.

Available Tools

11 tools
fetch_l402Fetch L402C

Fetch a paid resource protected by L402

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesthe URL to fetch
methodNoHTTP request method. Default GET
bodyNoHTTP request body as a string (either plaintext or stringified JSON)

Output Schema

ParametersJSON Schema
NameRequiredDescription
contentYesResponse content

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states 'Fetch' but does not indicate that payment or handling of L402 challenges may be required, nor what the output schema entails.

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 a single concise sentence with no unnecessary words. It is front-loaded with the purpose, but could benefit from additional detail without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description omits critical context about L402 protocol, payment handling, and expected outcomes. For a financial tool, this is insufficient.

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 schema already documents all parameters. The description adds no additional semantic value beyond what is in the schema.

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 'Fetch a paid resource protected by L402' clearly states the verb (Fetch) and the resource (paid L402-protected resource). It distinguishes from siblings implicitly as no other tool fetches resources. However, it assumes knowledge of L402 protocol.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like pay_invoice. The description provides no context for appropriate usage or prerequisites.

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

fiat_to_satsFiat To SatsB

Convert fiat amounts to sats

ParametersJSON Schema
NameRequiredDescriptionDefault
fiat_currencyYesthe fiat currency (e.g., USD, EUR)
fiat_amountYesfiat amount to convert

Output Schema

ParametersJSON Schema
NameRequiredDescription
amount_in_satsYesAmount in sats

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It does not mention whether conversion uses real-time rates, incurs network calls, or has side effects. This omission could lead to misuse.

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 a single sentence that gets straight to the point. It is front-loaded with the verb and resource, but could include more contextual structure while remaining concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description fails to mention any conversion semantics (e.g., exchange rate source, real-time vs fixed). For a simple tool, this lack of context reduces completeness.

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% and both parameters have clear descriptions (currency with example, amount as number). The description adds no additional meaning, so baseline score applies.

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 action ('Convert') and the resource ('fiat amounts to sats'), making the purpose unambiguous. It differentiates from siblings like pay_invoice or get_balance, as none perform conversion.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or common scenarios. Without context, an agent cannot decide if this is appropriate.

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

get_balanceGet BalanceB

Get the balance of the connected lightning wallet

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
amount_in_satsYesCurrent wallet balance in sats

TDQS

B3.1/5.0
Behavior2/5

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

No annotations provided. The description only states the action without disclosing behavioral traits like read-only nature, latency, or required authentication. With no annotations, the description carries the full burden and fails to add any transparency beyond the obvious.

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?

One short sentence with no extraneous text. It is appropriately sized for a simple tool, though it could be slightly more informative without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with an output schema, the description is minimal but may be sufficient if the output schema details the return format. However, it lacks context about wallet connection state, units, or error scenarios, leaving room for improvement.

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?

Zero parameters, input schema has 100% coverage. Baseline of 4 is appropriate as the description adds no parameter information, but none is needed.

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?

Clearly states verb 'Get' and resource 'balance of the connected lightning wallet'. Distinguishes from sibling tools which focus on other wallet operations like transactions or invoice management.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. For a simple zero-parameter tool this is somewhat acceptable, but the description provides no context about prerequisites (e.g., wallet must be connected) or scenarios where it is appropriate.

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

get_infoGet InfoA

Get NWC capabilities of the connected lightning wallet, and general information about the wallet and underlying lightning node

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
aliasNoNode alias
colorNoNode color
pubkeyNoNode public key
networkNoBitcoin Network (mainnet/testnet)
block_heightNoCurrent block height
block_hashNoCurrent block hash
methodsYesNWC methods supported by this connection
notificationsNoNWC notification types supported by this connection
metadataNoAdditional metadata about this connection
lud16NoLightning address of the wallet

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description must disclose behavioral traits. It implies a read-only operation via 'Get' but does not explicitly state non-destructiveness, rate limits, or permission requirements. The lack of explicit safety declarations limits transparency.

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 two sentences, concise, front-loaded with the primary action, and contains no unnecessary words. Every sentence contributes meaning.

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 zero-parameter tool and presence of an output schema, the description is largely complete. However, it could briefly mention that the output schema includes the mentioned capabilities, but overall it adequately describes the tool's purpose for a simple info retrieval.

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?

The input schema has no parameters, so the description adds value by specifying what information is returned (NWC capabilities, wallet/node info). Since schema coverage is 100%, a baseline of 3 applies, but the description effectively compensates by clarifying the output's scope.

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 retrieves 'NWC capabilities' and 'general information about the wallet and underlying lightning node'. The verb 'Get' is specific, and the resource is well-defined, distinguishing it from sibling tools like get_balance or list_transactions.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as get_wallet_service_info or get_balance. It lacks explicit context for optimal usage, leaving the agent to infer without support.

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

get_wallet_service_infoGet Wallet Service InfoA

Get NWC capabilities, supported encryption and notification types of the connected lightning wallet

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
capabilitiesYesCapabilities supported by this wallet - for example, NWC methods like 'pay_invoice', and 'notifications' if any notification types are supported.
encryptionsNoNWC encryption types supported by this connection
notificationsNoNWC notification types supported by this connection

TDQS

A3.6/5.0
Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It does not indicate whether the tool is read-only, idempotent, or has any side effects, nor does it mention potential network calls or authentication 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 a single, well-front-loaded sentence with no unnecessary words. Every word adds value.

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?

For a tool with no parameters and a known output schema, the description is sufficient. It identifies the output categories (capabilities, encryption, notification types) and implies the context (connected lightning wallet). Could be enhanced with a note on typical use, but it is largely complete.

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?

The input schema has zero parameters, so schema coverage is trivially 100%. According to the baseline rule, this warrants a score of 4. The description does not need to add parameter details.

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?

Description clearly states the tool retrieves NWC capabilities, supported encryption, and notification types of the connected lightning wallet. It specifies a distinct resource (wallet service info) and uses a specific verb ('Get'), differentiating it from siblings like get_balance or get_info.

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

Usage Guidelines2/5

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

The description provides no guidance on when or when not to use this tool, nor does it mention alternatives. It simply states what the tool does without context for selection.

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

list_transactionsList TransactionsC

List all transactions from the connected wallet with optional filtering by time, type, and limit

ParametersJSON Schema
NameRequiredDescriptionDefault
fromNo
untilNo
limitNo
offsetNo
typeNo
unpaidNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
transactionsYesList of transactions
total_countNoTotal number of transactions

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It only states 'List all transactions' without mentioning pagination, ordering, error conditions, or any side effects. The safety and read-only nature are not clarified.

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 a single sentence that front-loads the core action and key features. Every word is purposeful, but it could be slightly expanded to improve completeness without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 6 optional parameters and no annotations, yet the description provides only a high-level overview. It lacks details on default values, output format, pagination behavior, and error handling. An output schema exists but the description does not reference it.

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?

The description groups filters by time, type, and limit, adding some context beyond the schema. However, it omits offset and unpaid parameters. Since each parameter already has a description in the schema, the tool description contributes limited additional value.

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 clearly states the tool lists transactions from the connected wallet and mentions optional filters. It distinguishes from sibling tools which focus on invoices, balance, or other operations.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as requiring a connected wallet, or when to use other tools like lookup_invoice or pay_invoice.

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

lookup_invoiceLookup InvoiceC

Look up lightning invoice details from a BOLT-11 invoice or payment hash

ParametersJSON Schema
NameRequiredDescriptionDefault
payment_hashNo
invoiceNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
typeYesTransaction type
stateNoTransaction state
invoiceYesBOLT-11 invoice
descriptionNoInvoice description
description_hashNoDescription hash
preimageNoPreimage of settled payment
payment_hashYesPayment hash
amount_in_satsYesAmount in sats
fees_paid_in_satsNoFees paid in sats
settled_atNoTimestamp, of settled payment
created_atYesCreation unix timestamp
expires_atNoExpiry unix timestamp
settle_deadlineNoHOLD invoice settle deadline
metadataNoAdditional metadata about the transaction

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only lookup, but does not mention side effects, error cases (e.g., invoice not found), authentication requirements, or any rate limits. The description is too brief to be fully transparent.

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 a single, concise sentence that conveys the core purpose without any extraneous words. It is efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (two optional parameters, an output schema exists), the description is adequate but leaves gaps. It does not address edge cases like what happens when neither parameter is provided or both are provided. However, for a basic lookup tool, it covers the essential function.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage per context, meaning the parameter descriptions in the schema are not counted. The description adds no information about the parameters (e.g., that exactly one must be provided, or how they relate to each other). This leaves the agent with insufficient guidance on parameter usage.

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 clearly states the verb 'look up' and the resource 'lightning invoice details'. It distinguishes the tool's function from siblings like 'parse_invoice' by specifying the input types (BOLT-11 invoice or payment hash). However, it does not explicitly differentiate it from similar tools like 'fetch_l402'.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. For example, it does not mention that only one of the two parameters should be provided, nor does it describe prerequisites or limitations.

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

make_invoiceMake InvoiceC

Create a lightning invoice

ParametersJSON Schema
NameRequiredDescriptionDefault
amount_in_satsYesamount in sats
expiryNo
descriptionNo
description_hashNo
metadataNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
typeYesTransaction type
stateNoTransaction state
invoiceYesBOLT-11 invoice
descriptionNoInvoice description
description_hashNoDescription hash
preimageNoPreimage of settled payment
payment_hashYesPayment hash
amount_in_satsYesAmount in sats
fees_paid_in_satsNoFees paid in sats
settled_atNoTimestamp, of settled payment
created_atYesCreation unix timestamp
expires_atNoExpiry unix timestamp
settle_deadlineNoHOLD invoice settle deadline
metadataNoAdditional metadata about the transaction

TDQS

C2.8/5.0
Behavior1/5

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

No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It merely states "Create a lightning invoice" without mentioning side effects, permissions required, rate limits, or whether the created invoice is stored on the server.

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 a single, efficient sentence with no extraneous content. However, it could be slightly more informative without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having 5 parameters and no annotations, the description provides no information about the output (though an output schema exists), error conditions, or the lifecycle of the created invoice. It is inadequate for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 20%, and the tool description does not mention any parameters. While the schema includes minimal descriptions, the description adds no additional meaning or constraints beyond what is already present.

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 "Create a lightning invoice" is a clear, specific verb+resource pairing. It distinguishes the tool from siblings like pay_invoice, lookup_invoice, and parse_invoice.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like request_invoice or pay_invoice. There is no mention of prerequisites, context, or exclusion criteria.

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

parse_invoiceParse InvoiceC

Parse a BOLT-11 lightning invoice

ParametersJSON Schema
NameRequiredDescriptionDefault
invoiceYesthe bolt11 invoice

Output Schema

ParametersJSON Schema
NameRequiredDescription
paymentRequestYesThe BOLT-11 payment request
paymentHashYesPayment hash
preimageYesPayment preimage if available
verifyYesURL to verify if the email was paid (LNURL-verify)
amount_in_satsYesAmount in sats
expiryNoExpiry time in seconds
timestampYesCreation unix timestamp
createdDateYesCreation date string
expiryDateNoExpiry date string
descriptionYesInvoice description
successActionYesSuccess action to initiate after the invoice has been paid

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It fails to indicate that parsing is a read-only operation or state any side effects, rate limits, or other behavioral traits. The agent cannot infer safety or idempotency from this description.

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 a single short sentence with no extraneous words. It is appropriately concise for a simple tool, though it could be slightly more informative (e.g., mentioning the output structure) without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one required parameter, no annotations) and the existence of an output schema, the description is still too minimal. It omits context such as typical use cases, relationship to sibling tools, or hint at the parsing output. For an agent to decide confidently, more information is needed.

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% (the only parameter 'invoice' has a description 'the bolt11 invoice'). The tool description adds no additional meaning beyond 'Parse a BOLT-11 lightning invoice', which essentially repeats the parameter's purpose. It does not provide format examples, constraints, or behavioral context for the parameter.

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 clearly states the tool parses a BOLT-11 lightning invoice, using the specific verb 'parse' and naming the resource type. However, it does not differentiate from sibling tools like lookup_invoice, which may also parse invoices. The purpose is clear but lacks context that distinguishes it.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as lookup_invoice or pay_invoice. There are no prerequisites, examples, or exclusions mentioned, leaving the agent without decision-making support.

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

pay_invoicePay InvoiceC

Pay a lightning invoice

ParametersJSON Schema
NameRequiredDescriptionDefault
invoiceYesThe lightning invoice to pay
amount_in_satsNo
metadataNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
preimageYesPayment preimage
fees_paid_in_satsNoFees paid in sats

TDQS

C2.7/5.0
Behavior2/5

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

With no annotations, the description only says 'pay', implying a mutation but failing to disclose side effects like balance deduction, failure modes, or irreversible nature.

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

Conciseness3/5

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

The description is a single sentence with no wasted words, but it is too sparse for the tool's complexity (3 parameters, no annotations), sacrificing completeness for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the number of parameters, lack of annotations, and presence of an output schema, the description omits essential context such as success/error behavior, amount handling, and result structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds no information about parameters; schema coverage is only 33% (one parameter described), so the tool's behavior on parameters is largely opaque.

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 action ('Pay') and the resource ('lightning invoice'), which is specific and distinct from sibling tools like make_invoice or lookup_invoice.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives (e.g., request_invoice, make_invoice), nor are there any prerequisites or contextual cues.

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

request_invoiceRequest InvoiceC

Request an invoice from a lightning address

ParametersJSON Schema
NameRequiredDescriptionDefault
lightning_addressYesthe recipient's lightning address
amount_in_satsYesamount in sats
descriptionNo
payer_dataNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
paymentRequestYesThe BOLT-11 payment request
paymentHashYesPayment hash
preimageYesPayment preimage if available
verifyYesURL to verify if the email was paid (LNURL-verify)
amount_in_satsYesAmount in sats
expiryNoExpiry time in seconds
timestampYesCreation unix timestamp
createdDateYesCreation date string
expiryDateNoExpiry date string
descriptionYesInvoice description
successActionYesSuccess action to initiate after the invoice has been paid

TDQS

C2.9/5.0
Behavior2/5

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

No annotations exist, so the description must fully disclose behavior. It only states the action without detailing what happens after the request (e.g., does it wait for an invoice, return it immediately, or require further steps?). No mention of side effects, permissions, or output format.

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?

Single sentence, no wasted words. It is appropriately brief for a simple action, though a bit more context could be added without harming conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, no annotations, and an output schema, the description is too minimal. It does not explain how the request process works, return value, or any prerequisites. The tool's behavior is underspecified.

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 provides descriptions for all parameters, so baseline is 3. The description adds no extra meaning beyond the schema, which already covers lightning_address, amount_in_sats, description, and payer_data adequately for their roles.

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?

Description clearly states the action: request an invoice from a lightning address. It specifies the verb and resource, and the lightning address identifies the recipient. While it distinguishes from siblings like make_invoice (which creates an invoice), it does not explicitly differentiate, but the purpose is clear.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like make_invoice or pay_invoice. The description implies the use case but provides no explicit context for choosing this over other tools.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 9 tool updatesv1.0.0
    • Changedfetch_l4025 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedInput schema / properties / body / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / body / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedInput schema / properties / method / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / method / type
        Removed value: -[
-  "string",
-  "null"
-]
    • Changedfiat_to_sats1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedget_info14 fields changed
      • addedOutput schema / properties / alias / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / alias / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / block_hash / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / block_hash / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / block_height / anyOf
        Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / block_height / type
        Removed value: -[
-  "number",
-  "null"
-]
      • addedOutput schema / properties / color / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / color / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / lud16 / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / lud16 / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / network / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / network / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / pubkey / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / pubkey / type
        Removed value: -[
-  "string",
-  "null"
-]
    • Changedlist_transactions33 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedInput schema / properties / from / anyOf
        Added value: +[
+  {
+    "description": "Start unix timestamp for filtering transactions (inclusive)",
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / from / description
        Removed value: -"Start unix timestamp for filtering transactions (inclusive)"
      • removedInput schema / properties / from / type
        Removed value: -[
-  "number",
-  "null"
-]
      • addedInput schema / properties / limit / anyOf
        Added value: +[
+  {
+    "description": "Maximum number of transactions to return",
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / limit / description
        Removed value: -"Maximum number of transactions to return"
      • removedInput schema / properties / limit / type
        Removed value: -[
-  "number",
-  "null"
-]
      • addedInput schema / properties / offset / anyOf
        Added value: +[
+  {
+    "description": "Offset of the first transaction to return",
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / offset / description
        Removed value: -"Offset of the first transaction to return"
      • removedInput schema / properties / offset / type
        Removed value: -[
-  "number",
-  "null"
-]
      • removedInput schema / properties / type / description
        Removed value: -"Filter transactions by type"
      • addedInput schema / properties / unpaid / anyOf
        Added value: +[
+  {
+    "description": "Filter for unpaid transactions only",
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / unpaid / description
        Removed value: -"Filter for unpaid transactions only"
      • removedInput schema / properties / unpaid / type
        Removed value: -[
-  "boolean",
-  "null"
-]
      • addedInput schema / properties / until / anyOf
        Added value: +[
+  {
+    "description": "End unix timestamp for filtering transactions (inclusive)",
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / until / description
        Removed value: -"End unix timestamp for filtering transactions (inclusive)"
      • removedInput schema / properties / until / type
        Removed value: -[
-  "number",
-  "null"
-]
      • addedOutput schema / properties / total_count / anyOf
        Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / total_count / type
        Removed value: -[
-  "number",
-  "null"
-]
      • addedOutput schema / properties / transactions / items / properties / description / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / transactions / items / properties / description / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / transactions / items / properties / description_hash / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / transactions / items / properties / description_hash / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / transactions / items / properties / expires_at / anyOf
        Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / transactions / items / properties / expires_at / type
        Removed value: -[
-  "number",
-  "null"
-]
      • addedOutput schema / properties / transactions / items / properties / fees_paid_in_sats / anyOf
        Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / transactions / items / properties / fees_paid_in_sats / type
        Removed value: -[
-  "number",
-  "null"
-]
      • addedOutput schema / properties / transactions / items / properties / preimage / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / transactions / items / properties / preimage / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / transactions / items / properties / settle_deadline / anyOf
        Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / transactions / items / properties / settle_deadline / type
        Removed value: -[
-  "number",
-  "null"
-]
      • addedOutput schema / properties / transactions / items / properties / settled_at / anyOf
        Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / transactions / items / properties / settled_at / type
        Removed value: -[
-  "number",
-  "null"
-]
    • Changedlookup_invoice21 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedInput schema / properties / invoice / anyOf
        Added value: +[
+  {
+    "description": "The BOLT 11 invoice to look up",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / invoice / description
        Removed value: -"The BOLT 11 invoice to look up"
      • removedInput schema / properties / invoice / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedInput schema / properties / payment_hash / anyOf
        Added value: +[
+  {
+    "description": "The payment hash of the invoice to look up",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / payment_hash / description
        Removed value: -"The payment hash of the invoice to look up"
      • removedInput schema / properties / payment_hash / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / description / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / description / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / description_hash / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / description_hash / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / expires_at / anyOf
        Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / expires_at / type
        Removed value: -[
-  "number",
-  "null"
-]
      • addedOutput schema / properties / fees_paid_in_sats / anyOf
        Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / fees_paid_in_sats / type
        Removed value: -[
-  "number",
-  "null"
-]
      • addedOutput schema / properties / preimage / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / preimage / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / settle_deadline / anyOf
        Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / settle_deadline / type
        Removed value: -[
-  "number",
-  "null"
-]
      • addedOutput schema / properties / settled_at / anyOf
        Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / settled_at / type
        Removed value: -[
-  "number",
-  "null"
-]
    • Changedmake_invoice26 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedInput schema / properties / description / anyOf
        Added value: +[
+  {
+    "description": "note, memo or description describing the invoice",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / description / description
        Removed value: -"note, memo or description describing the invoice"
      • removedInput schema / properties / description / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedInput schema / properties / description_hash / anyOf
        Added value: +[
+  {
+    "description": "hash of a note, memo or description that is too long to fit within the invoice",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / description_hash / description
        Removed value: -"hash of a note, memo or description that is too long to fit within the invoice"
      • removedInput schema / properties / description_hash / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedInput schema / properties / expiry / anyOf
        Added value: +[
+  {
+    "description": "expiry in seconds",
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / expiry / description
        Removed value: -"expiry in seconds"
      • removedInput schema / properties / expiry / type
        Removed value: -[
-  "number",
-  "null"
-]
      • changedInput schema / properties / metadata / anyOf
        Previous value: -[
-  {
-    "additionalProperties": true,
-    "description": "Optional metadata to include with the payment",
-    "properties": {},
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": {},
+    "description": "Optional metadata to include with the payment",
+    "properties": {},
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / metadata / description
        Removed value: -"Optional metadata to include with the payment"
      • addedOutput schema / properties / description / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / description / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / description_hash / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / description_hash / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / expires_at / anyOf
        Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / expires_at / type
        Removed value: -[
-  "number",
-  "null"
-]
      • addedOutput schema / properties / fees_paid_in_sats / anyOf
        Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / fees_paid_in_sats / type
        Removed value: -[
-  "number",
-  "null"
-]
      • addedOutput schema / properties / preimage / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / preimage / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / settle_deadline / anyOf
        Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / settle_deadline / type
        Removed value: -[
-  "number",
-  "null"
-]
      • addedOutput schema / properties / settled_at / anyOf
        Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / settled_at / type
        Removed value: -[
-  "number",
-  "null"
-]
    • Changedparse_invoice12 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedOutput schema / properties / description / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / description / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / expiry / anyOf
        Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / expiry / type
        Removed value: -[
-  "number",
-  "null"
-]
      • addedOutput schema / properties / expiryDate / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / expiryDate / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / preimage / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / preimage / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / verify / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / verify / type
        Removed value: -[
-  "string",
-  "null"
-]
      • changedOutput schema / required
        Previous value: -[
-  "paymentRequest",
-  "paymentHash",
-  "preimage",
-  "verify",
-  "amount_in_sats",
-  "timestamp",
-  "createdDate",
-  "description"
-]New value: +[
+  "paymentRequest",
+  "paymentHash",
+  "preimage",
+  "verify",
+  "amount_in_sats",
+  "timestamp",
+  "createdDate",
+  "description",
+  "successAction"
+]
    • Changedpay_invoice8 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedInput schema / properties / amount_in_sats / anyOf
        Added value: +[
+  {
+    "description": "Optional amount in sats, only provide if paying a zero-amount invoice",
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / amount_in_sats / description
        Removed value: -"Optional amount in sats, only provide if paying a zero-amount invoice"
      • removedInput schema / properties / amount_in_sats / type
        Removed value: -[
-  "number",
-  "null"
-]
      • changedInput schema / properties / metadata / anyOf
        Previous value: -[
-  {
-    "additionalProperties": true,
-    "description": "Optional metadata to include with the payment",
-    "properties": {},
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": {},
+    "description": "Optional metadata to include with the payment",
+    "properties": {},
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / metadata / description
        Removed value: -"Optional metadata to include with the payment"
      • addedOutput schema / properties / fees_paid_in_sats / anyOf
        Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / fees_paid_in_sats / type
        Removed value: -[
-  "number",
-  "null"
-]
    • Changedrequest_invoice17 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedInput schema / properties / description / anyOf
        Added value: +[
+  {
+    "description": "note, memo or description describing the invoice",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / description / description
        Removed value: -"note, memo or description describing the invoice"
      • removedInput schema / properties / description / type
        Removed value: -[
-  "string",
-  "null"
-]
      • changedInput schema / properties / payer_data / anyOf
        Previous value: -[
-  {
-    "additionalProperties": true,
-    "description": "metadata to include with the payment such as the payer's name",
-    "properties": {},
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": {},
+    "description": "metadata to include with the payment such as the payer's name",
+    "properties": {},
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / payer_data / description
        Removed value: -"metadata to include with the payment such as the payer's name"
      • addedOutput schema / properties / description / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / description / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / expiry / anyOf
        Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / expiry / type
        Removed value: -[
-  "number",
-  "null"
-]
      • addedOutput schema / properties / expiryDate / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / expiryDate / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / preimage / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / preimage / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / verify / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / verify / type
        Removed value: -[
-  "string",
-  "null"
-]
      • changedOutput schema / required
        Previous value: -[
-  "paymentRequest",
-  "paymentHash",
-  "preimage",
-  "verify",
-  "amount_in_sats",
-  "timestamp",
-  "createdDate",
-  "description"
-]New value: +[
+  "paymentRequest",
+  "paymentHash",
+  "preimage",
+  "verify",
+  "amount_in_sats",
+  "timestamp",
+  "createdDate",
+  "description",
+  "successAction"
+]
  2. 11 tool updates
    • First observedfetch_l402
    • First observedfiat_to_sats
    • First observedget_balance
    • First observedget_info
    • First observedget_wallet_service_info
    • First observedlist_transactions
    • First observedlookup_invoice
    • First observedmake_invoice
    • First observedparse_invoice
    • First observedpay_invoice
    • First observedrequest_invoice
Deploy Server
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

TDQS

B3.3/5.0

Scored across 11 tools

Disambiguation4/5

Most tools have distinct purposes, but get_info and get_wallet_service_info overlap significantly, both providing NWC capabilities and wallet details, which could cause confusion for an agent.

Naming Consistency4/5

All tool names use snake_case and generally follow a verb_noun pattern, though fiat_to_sats deviates slightly by lacking a verb, and the mix of verbs like 'get', 'list', 'lookup', 'make', etc. is acceptable.

Tool Count5/5

With 11 tools covering balance, transactions, invoices, payments, L402, fiat conversion, and wallet info, the count is well-scoped for a Bitcoin payments server.

Completeness4/5

Core payment workflows (create, pay, lookup invoices, get balance, list transactions) are covered, but missing support for spontaneous payments (keysend) and advanced node management leaves minor gaps.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches