Lightning Enable MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, such as access_l402_resource for automated payments, pay_invoice for direct payments, and create_l402_challenge for charging others. However, some overlap exists between check_invoice_status and verify_l402_payment, which both involve payment verification but target different contexts, potentially causing minor confusion.
Naming Consistency5/5
Tool names consistently follow a verb_noun pattern with snake_case throughout, such as access_l402_resource, check_invoice_status, and configure_budget. This uniformity makes the set predictable and easy to understand, with no deviations in naming conventions.
Tool Count4/5
With 17 tools, the count is slightly high but reasonable for the server's scope in Lightning payments and L402 protocol management. It covers various aspects like payments, invoices, budgets, and API discovery, though it might feel a bit heavy compared to more focused servers.
Completeness5/5
The tool set provides comprehensive coverage for Lightning and L402 operations, including creating and paying invoices, managing budgets, verifying payments, and handling on-chain transactions. No obvious gaps are present; it supports full workflows from payment initiation to confirmation and resource access.
Average 3.5/5 across 17 of 17 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 95 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Set' implies a configuration/mutation action, it doesn't specify whether changes are persistent, reversible, or require specific permissions. It also doesn't mention what happens when limits are exceeded or if there are rate limits on configuration changes.
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, efficient sentence with zero wasted words. It's appropriately sized for a simple configuration tool and gets straight to the point without unnecessary elaboration.
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?
For a budget configuration tool in a payment/transaction system with no annotations and no output schema, the description is inadequate. It doesn't explain the relationship to other payment tools, what units are used (satoshis are only mentioned in schema), whether configuration is persistent, or what happens when limits are reached during payment operations.
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%, with both parameters ('per_request' and 'per_session') clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline for high schema coverage.
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 'Set spending limits for the session' clearly states the verb ('Set') and resource ('spending limits'), with 'for the session' providing useful scope context. However, it doesn't differentiate from sibling tools like 'get_budget_status' or explain how this relates to payment operations in the broader toolset.
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. It doesn't mention prerequisites (e.g., whether a budget must be configured before making payments), when it should be invoked (e.g., at session start), or how it interacts with sibling payment tools like 'pay_invoice' or 'get_budget_status'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It doesn't disclose whether this is a read-only operation, if it requires authentication, rate limits, error conditions, or what 'session' means contextually. The phrase 'List recent' implies safe retrieval, but specifics are missing.
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, efficient sentence with zero waste—it directly states the tool's function and scope without redundancy. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 no annotations and no output schema, the description is incomplete for a tool with 2 parameters and multiple siblings. It doesn't explain return values (e.g., payment details format), error handling, or how 'session' interacts with parameters like 'since'. For a payment history tool in a complex L402 context, more guidance 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 description coverage is 100%, so parameters 'limit' and 'since' are well-documented in the schema. The description adds no additional parameter semantics beyond implying temporal filtering ('recent', 'during this session'), which aligns with but doesn't expand on the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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's purpose with a specific verb ('List') and resource ('L402 payments'), and specifies scope ('recent', 'made during this session'). However, it doesn't explicitly differentiate from sibling tools like 'check_invoice_status' or 'verify_l402_payment' that might also relate to payments.
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 minimal guidance by implying usage for recent session payments, but offers no explicit when-to-use rules, no alternatives among siblings (e.g., vs. 'get_all_balances' for broader data), and no prerequisites or exclusions. This leaves the agent with little context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action is a payment but does not disclose behavioral traits such as transaction irreversibility, network fees, confirmation times, authentication requirements, or rate limits. The Strike wallet mention adds some context but is insufficient for a mutation tool with no annotation coverage.
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 that directly states the tool's function. It is appropriately sized and front-loaded, with no wasted words, though it could be slightly more structured by separating functional details from limitations.
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 complexity of a financial transaction tool with no annotations and no output schema, the description is incomplete. It lacks critical information such as return values, error conditions, security implications, or how it differs from other payment-related sibling tools, making it inadequate for safe and effective use.
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 both parameters ('address' and 'amount_sats') adequately. The description does not add any meaning beyond what the schema provides, such as format examples or constraints, but the high coverage justifies the baseline score of 3.
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 action ('send') and resource ('on-chain Bitcoin payment to a Bitcoin address'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'pay_invoice' or 'pay_l402_challenge', which might also involve payments but through different mechanisms, so it lacks sibling distinction.
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. It mentions 'Currently only available with Strike wallet,' which is a limitation but not a usage guideline. There is no indication of prerequisites, when-not-to-use scenarios, or comparisons to sibling tools like 'pay_invoice' for off-chain payments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool checks a balance but doesn't describe what 'connected' means, potential errors (e.g., if wallet is disconnected), rate limits, authentication needs, or the return format. This leaves significant gaps for a tool that likely interacts with financial data.
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, efficient sentence with zero waste. It front-loads the key action ('Check') and resource, and every word ('connected Lightning wallet balance via NWC') adds specific value without redundancy. This is optimally concise for a no-parameter tool.
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 complexity of financial tools and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'NWC' is, what the balance includes (e.g., on-chain vs. Lightning), error handling, or return format. For a tool that likely returns critical financial data, this leaves too much unspecified.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and the baseline for 0 parameters is 4, as it avoids unnecessary details while clearly stating the tool's purpose.
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 action ('Check') and resource ('connected Lightning wallet balance'), and specifies the method ('via NWC'). It distinguishes from siblings like 'get_all_balances' by focusing on a specific wallet. However, it doesn't explicitly differentiate from all siblings, such as 'get_budget_status', which might also involve balance-related checks.
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. It doesn't mention prerequisites (e.g., wallet connection), exclusions, or compare it to siblings like 'get_all_balances' (which might return multiple balances) or 'get_budget_status' (which could involve budget-specific checks). Usage is implied only by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the wallet restriction but doesn't cover critical aspects like whether this is a live transaction (destructive), what permissions are needed, potential fees, rate limits, or what happens on failure. For a financial transaction tool with zero annotation coverage, this leaves significant behavioral gaps.
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 appropriately brief with two clear sentences. The first states the core functionality, the second adds an important constraint. There's no wasted language, though it could be slightly more structured by front-loading the most critical information about it being a transactional operation.
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?
For a financial transaction tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (transaction ID, confirmation, error messages), doesn't cover error conditions, and provides minimal behavioral context. Given the complexity and risk profile of currency exchange, more completeness 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 description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond what's in the schema - it mentions the currency pairs but doesn't provide additional context about format, constraints, or edge cases. This meets the baseline for high schema coverage.
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's purpose: 'Exchange currency within your wallet' with specific directionality (USD to BTC or BTC to USD). It distinguishes from siblings by focusing on currency conversion rather than invoice management, payments, or balance checking. However, it doesn't explicitly differentiate from all possible alternatives like 'get_btc_price' which provides pricing information but not conversion.
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 provides some context with 'Currently only available with Strike wallet,' which implies a prerequisite wallet type. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_btc_price' for pricing information or 'send_onchain' for transfers. The guidance is implied rather than explicit about use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It states the tool checks if an invoice has been paid, which implies a read-only operation, but it does not disclose critical behavioral traits such as authentication requirements, rate limits, error handling, or what the output looks like (e.g., status codes or data format). This is a significant gap for a tool with no annotation coverage.
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 and front-loaded, consisting of just two sentences that directly state the tool's purpose and input source. There is no wasted language, and every sentence earns its place by providing essential information efficiently.
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 complexity of checking invoice status in a Lightning network context, the description is incomplete. There is no output schema, and the description does not explain return values (e.g., paid/unpaid status, timestamps, or error messages). With no annotations and minimal behavioral details, the description fails to provide enough context for effective tool use, especially in a system with multiple payment-related siblings.
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 input schema has 100% description coverage, with the parameter 'invoice_id' fully documented. The description adds minimal value beyond the schema by reiterating that the invoice ID comes from 'create_invoice', but it does not provide additional semantics like format examples or constraints. Given the high schema coverage, the baseline score of 3 is appropriate.
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's purpose with a specific verb ('check') and resource ('Lightning invoice status'), and it identifies the required input ('invoice ID from create_invoice'). However, it does not explicitly differentiate this tool from potential siblings like 'confirm_payment' or 'get_payment_history', which might offer overlapping functionality, so it falls short of a perfect score.
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 provides implied usage by specifying to 'Use the invoice ID from create_invoice', which suggests a prerequisite and context. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., 'confirm_payment' or 'get_payment_history'), and it does not mention any exclusions or edge cases, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return type (BOLT11 string) but omits critical details: whether this is a read-only or mutating operation, authentication requirements, rate limits, error conditions, or what happens after creation (e.g., invoice lifecycle).
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 concise sentences with zero waste. The first sentence states the purpose, and the second explains the return value. It's front-loaded and efficiently structured.
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?
For a financial tool with no annotations and no output schema, the description is incomplete. It lacks details on authentication, error handling, invoice lifecycle, and how the returned string should be used. Given the complexity of Lightning payments, more context is needed for safe and effective use.
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 fully documents all parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain BOLT11 format constraints or memo usage). Baseline 3 is appropriate when the schema does the heavy lifting.
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 specific action ('Create a Lightning invoice'), the resource ('to receive a payment'), and the outcome ('Returns a BOLT11 invoice string'). It distinguishes itself from siblings like 'pay_invoice' (which sends payments) and 'check_invoice_status' (which queries status).
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. It doesn't mention prerequisites (e.g., wallet setup), when not to use it (e.g., for on-chain payments), or how it relates to siblings like 'create_l402_challenge' or 'pay_invoice'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It mentions the tool retrieves balances but doesn't cover critical aspects like authentication needs, rate limits, error handling, or whether it's a read-only operation. This leaves significant gaps in understanding how the tool behaves in practice.
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 concise with two sentences that directly state the purpose and a usage tip. It's front-loaded with the core functionality and avoids unnecessary details, though the second sentence could be slightly more integrated to enhance flow.
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 complexity (retrieving financial data) and lack of annotations and output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral traits like security requirements. For a tool handling sensitive wallet data, this leaves too many unknowns for effective use.
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 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, which is acceptable since there are no parameters to describe. A baseline of 4 is appropriate as it doesn't need to compensate for missing schema information.
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 action ('Get all currency balances') and resource ('from your wallet'), specifying the scope includes multiple currencies like USD and BTC. However, it doesn't explicitly differentiate from sibling tools like 'check_wallet_balance', which might have overlapping functionality, preventing a perfect score.
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 by mentioning it's 'Most useful with Strike wallet which supports multiple currencies,' suggesting a preferred context but not providing explicit guidance on when to use this tool versus alternatives like 'check_wallet_balance'. No exclusions or clear alternatives are stated, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions the outcome ('receive the authorization token') and a behavioral note about omitting macaroon for MPP mode, but it lacks critical details: it doesn't specify whether this is a read-only or destructive operation, what happens on failure, rate limits, or authentication requirements. For a payment tool with no annotations, this is insufficient.
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 concise with two sentences that are directly relevant. The first sentence states the purpose and outcome, and the second provides a usage note. There's no fluff, but it could be slightly more structured by front-loading key distinctions from siblings.
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 no annotations and no output schema, the description is incomplete. It covers the basic purpose and a usage hint but misses behavioral traits (e.g., side effects, error handling) and output details. For a payment tool with 3 parameters and no structured safety hints, this leaves significant gaps for an AI agent to understand full context.
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 well. The description adds minimal value: it reiterates that macaroon should be omitted for MPP mode (which is also in the schema) and implies the tool handles both L402 and MPP flows. No additional syntax, format, or contextual details beyond the schema are provided, meeting the baseline for high coverage.
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's purpose: 'Manually pay an L402 or MPP invoice and receive the authorization token.' It specifies the verb ('pay'), resource ('invoice'), and outcome ('receive the authorization token'). However, it doesn't explicitly distinguish this from sibling tools like 'pay_invoice' or 'verify_l402_payment', which reduces clarity about when to choose this specific tool.
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 provides some usage context: 'Use this if you need to handle the L402/MPP flow yourself.' This implies it's for manual handling of these protocols, but it doesn't explicitly state when to use this versus alternatives like 'pay_invoice' or 'access_l402_resource'. No exclusions or prerequisites are mentioned, leaving gaps in guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 the tool is 'read-only', which is a key behavioral trait for safety. However, it doesn't mention other aspects like rate limits, authentication needs, error conditions, or what 'budget status' entails (e.g., timeframes, currency). The config file mention is extraneous to tool behavior.
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 concise with two sentences, but the second sentence about editing a config file is not directly relevant to tool usage and could be considered wasteful. The first sentence efficiently states the purpose and read-only nature. Overall, it's well-structured but includes minor extraneous information.
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 (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and safety (read-only), but lacks details on what 'budget status' includes (e.g., values, format) or behavioral context like response structure. For a tool with no structured data, it should provide more completeness about outputs or usage 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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is appropriate here. Baseline is 4 for 0 parameters, as no compensation 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?
The description clearly states the tool's purpose: 'View current budget status and spending limits' with the specific verb 'view' and resource 'budget status and spending limits'. It distinguishes from siblings like 'configure_budget' (which edits) by specifying 'read-only', but doesn't explicitly differentiate from other read tools like 'get_all_balances' or 'check_wallet_balance' beyond the resource focus.
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 minimal guidance: it states the tool is 'read-only' and mentions editing a config file to change limits, but this is not a usage guideline for the tool itself. It lacks explicit when-to-use instructions, prerequisites, or alternatives among siblings (e.g., vs. 'get_all_balances' or 'configure_budget'), leaving the agent to infer based on purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It mentions the output ('preimage as proof of payment') but lacks details on permissions, rate limits, error handling, or what happens if payment fails. For a payment tool with zero annotation coverage, this is insufficient for safe agent use.
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 with zero waste: the first states the purpose and output, and the second provides usage context. It is front-loaded with key information and appropriately sized for the tool's complexity.
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 no annotations and no output schema, the description should do more to explain behavioral aspects like payment confirmation flow (hinted by the 'confirmed' parameter) or error cases. It covers basic purpose and usage but lacks completeness for a payment operation with potential financial implications.
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 fully documents the parameters. The description does not add any semantic details beyond what the schema provides (e.g., it doesn't explain invoice format or max_sats implications). Baseline 3 is appropriate as the schema handles parameter documentation adequately.
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 a Lightning invoice directly') and the resource ('BOLT11 Lightning invoice'), distinguishing it from siblings like 'pay_l402_challenge' by specifying 'without L402 protocol overhead'. It also mentions the output ('get the preimage as proof of payment'), making the purpose specific and well-defined.
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?
The description provides clear context for when to use this tool ('to pay any BOLT11 Lightning invoice without L402 protocol overhead'), implicitly distinguishing it from 'pay_l402_challenge'. However, it does not explicitly state when not to use it or mention alternatives like 'send_onchain' for non-Lightning payments, leaving some guidance gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the automatic payment and retry behavior, which is valuable, but lacks details on error handling, rate limits, authentication needs, or what happens if payment fails. It adequately describes the core behavior but misses additional operational context.
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, front-loaded with the main purpose and followed by key behavioral detail. Every sentence earns its place by explaining the tool's unique functionality without redundancy or unnecessary elaboration.
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 complexity (6 parameters, no output schema, no annotations), the description covers the core purpose and payment retry behavior but lacks details on return values, error cases, or integration with sibling tools. It is minimally adequate but has clear gaps for a tool with this level of complexity.
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 thoroughly. The description does not add any parameter-specific semantics beyond what the schema provides, such as examples or usage nuances, meeting the baseline for high schema coverage.
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 ('fetch') and resource ('URL'), and distinguishes it from siblings by mentioning 'automatic L402 payment handling' and '402 Payment Required response' retry logic, which no other sibling tool describes.
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?
The description provides clear context for when to use this tool ('fetch a URL with automatic L402 payment handling'), but it does not explicitly mention when not to use it or name alternatives among siblings, such as simpler fetch tools or manual payment handling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the dependency on 'Strike wallet,' which is useful context, but lacks details on rate limits, error handling, or response format. The description does not contradict annotations, but it could provide more behavioral insights for a tool with external dependencies.
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 highly concise and front-loaded, consisting of two sentences that efficiently convey the core functionality and a critical constraint. Every word serves a purpose, with no redundant or unnecessary information, making it easy to parse quickly.
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 (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains what the tool does and a key dependency, but lacks details on return values (e.g., numeric price, timestamp) or potential errors, which could hinder an agent's ability to use it effectively without trial and error.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and constraints, which aligns with the baseline expectation for zero-parameter tools.
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 specific action ('Get'), resource ('current Bitcoin price'), and unit ('in USD'), making the purpose unambiguous. It distinguishes itself from siblings like 'exchange_currency' by focusing solely on Bitcoin price retrieval without conversion or other financial operations.
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?
The description provides clear context by specifying 'Only available with Strike wallet,' which indicates a prerequisite or dependency. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'exchange_currency' for other currencies or conversions), leaving some ambiguity in sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies this is a mutation tool (confirmation changes state), but doesn't disclose behavioral traits like permissions needed, rate limits, or what happens on failure. It adds some context about the trigger condition, but lacks details on outcomes or error handling.
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?
Two sentences with zero waste: the first states purpose and parameter source, the second provides precise usage timing. It's front-loaded with essential information and appropriately sized for a single-parameter tool.
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 (simple confirmation action), 1 parameter with full schema coverage, and no output schema, the description is mostly complete. It covers purpose, usage context, and parameter origin, but lacks details on return values or error behavior that would be helpful for a mutation tool with no annotations.
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 the 'nonce' parameter fully. The description adds minimal value beyond the schema by mentioning it's 'from a previous payment request' and '6-character', but these details are already implied or stated in the schema description. Baseline 3 is appropriate when schema does the heavy lifting.
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 specific action ('Confirm a pending payment') and resource ('using the nonce code from a previous payment request'), distinguishing it from siblings like pay_invoice or verify_l402_payment by focusing on confirmation rather than initiation or verification.
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 states when to use this tool ('Call this after a payment tool returns requiresConfirmation=true with a nonce'), providing clear context and prerequisites without misleading information about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behaviors: it returns specific outputs (Lightning invoice and macaroon), outlines the payer's required actions (pay invoice and present token), and mentions authentication needs (API key requirement). However, it lacks details on rate limits or error handling.
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 appropriately sized and front-loaded, with three concise sentences that each add value: the first states the purpose, the second explains the return and process, and the third notes prerequisites, with no wasted words.
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 challenge creation) and lack of output schema, the description is fairly complete, covering purpose, process, and prerequisites. However, it could benefit from more details on output format or error cases to fully compensate for the missing structured data.
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 meaning beyond what the schema provides, such as examples or usage context for parameters like 'resource' or 'price_sats', meeting the baseline for high coverage.
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 specific verbs ('create', 'charge') and resource ('L402 payment challenge'), distinguishing it from siblings like 'create_invoice' or 'pay_l402_challenge' by focusing on generating a challenge for accessing resources.
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?
It provides clear context on when to use this tool (to charge for resource access) and mentions prerequisites (requires LIGHTNING_ENABLE_API_KEY with Agentic Commerce subscription), but does not explicitly state when not to use it or name alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool can show 'affordable call counts based on remaining budget' with budget_aware=true, which is useful behavioral context. However, it doesn't mention rate limits, authentication needs, or what happens when multiple parameters are provided simultaneously.
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 front-loaded with the core purpose, followed by specific usage instructions for each parameter. Every sentence earns its place by providing distinct guidance. It's appropriately sized for a tool with four parameters and no annotations.
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 moderate complexity (4 parameters, no output schema, no annotations), the description is mostly complete. It explains what the tool does, how to use different parameters, and a key behavioral feature (budget awareness). The main gap is lack of output format details, but with no output schema, this would be helpful.
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 description coverage is 100%, so the schema already documents all parameters well. The description adds value by explaining the semantic relationship between parameters: url fetches a specific API, query searches by keyword, category filters by category, and budget_aware affects affordability display. This goes beyond the schema's individual parameter descriptions.
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: 'Discover L402-enabled APIs' with specific verbs (search, fetch, browse) and resources (APIs, manifests, endpoints, pricing). It distinguishes from siblings like 'access_l402_resource' (which likely accesses specific APIs) by focusing on discovery rather than usage.
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?
The description provides explicit guidance on when to use different parameters: 'Use 'query' to search...', 'use 'url' to fetch...', 'Use 'category' to browse...'. It also specifies 'If omitted, searches the registry instead' for the url parameter, offering clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's function (verification), context (post-payment validation), and prerequisites (API key requirement), though it lacks details on rate limits, error handling, or response format.
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 front-loaded with the core purpose, followed by usage context and prerequisites in two efficient sentences. Every sentence adds value without redundancy, making it appropriately concise and well-structured.
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 moderate complexity (verification with prerequisites), no annotations, and no output schema, the description is largely complete—covering purpose, usage, and requirements. However, it lacks details on return values or error cases, which would enhance 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 description coverage is 100%, so the schema already documents both parameters ('macaroon' and 'preimage') with their formats. The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline for high coverage.
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 specific verbs ('verify', 'confirm') and resources ('L402 token', 'payment'), distinguishing it from siblings like 'check_invoice_status' or 'confirm_payment' by focusing on token validation rather than payment tracking or confirmation.
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 states when to use this tool ('after receiving an L402 token from a payer to validate they paid before granting access to the resource') and provides context on prerequisites ('Requires LIGHTNING_ENABLE_API_KEY with an Agentic Commerce subscription'), clearly differentiating it from alternatives like 'access_l402_resource'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![lightning-enable-mcp MCP server](https://glama.ai/mcp/servers/refined-element/lightning-enable-mcp/badges/card.svg)](https://glama.ai/mcp/servers/refined-element/lightning-enable-mcp)

Score Badge

Copy to your README.md:

[![lightning-enable-mcp MCP server](https://glama.ai/mcp/servers/refined-element/lightning-enable-mcp/badges/score.svg)](https://glama.ai/mcp/servers/refined-element/lightning-enable-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/refined-element/lightning-enable-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server