AgentBTC MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap. For example, create_lightning_invoice is for receiving payments, pay_lightning_invoice is for sending payments, and decode_invoice is for inspection, making misselection unlikely. The separation between wallet management (create_agent_wallet, delete_agent_wallet), balance/status queries (get_agent_balance, check_channel_balance), and payment operations is well-defined.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern with snake_case throughout, such as create_lightning_invoice and get_agent_balance. There is one minor deviation: access_l402_api uses an acronym (L402) instead of a full noun, but this is understandable given the technical context and does not break the overall pattern.
Tool Count5/5
With 13 tools, the count is well-scoped for a Bitcoin/Lightning server, covering key areas like wallet management, payments, and network status. Each tool earns its place by addressing specific needs in the domain, such as creating invoices, checking balances, and managing channels, without being excessive or sparse.
Completeness5/5
The tool set provides complete coverage for Bitcoin and Lightning Network operations, including CRUD for wallets (create, list, get balance, delete), payment lifecycle (create invoice, decode, pay, send via address), and network monitoring (node info, channel list, transaction history). No obvious gaps exist for core workflows in this domain.
Average 3.3/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
Add a glama.json file to provide metadata about your server.
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.
Add related servers to improve discoverability.

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?
No annotations are provided, so the description carries the full burden. It mentions 'automatic Lightning payment,' implying transactional behavior, but doesn't disclose critical details: whether this deducts from a balance, requires authentication, has rate limits, or what happens on failure (e.g., payment errors). For a tool involving payments and API access, this is inadequate.
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 that front-loads the core functionality ('Access an L402-protected API endpoint') and adds key detail ('with automatic Lightning payment'). There is zero waste, making it highly concise and well-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?
Given the complexity (payment-involved API access), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values, error handling, or behavioral nuances like payment confirmation. For a tool with financial implications, this leaves too many unknowns for safe agent 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 ('endpoint' with enum values, 'symbol' with default). The description adds no additional meaning beyond implying the tool uses these for API access and payments. This meets the baseline of 3 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.
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: 'Access an L402-protected API endpoint with automatic Lightning payment.' It specifies the verb ('access'), resource ('L402-protected API endpoint'), and key capability ('automatic Lightning payment'). However, it doesn't explicitly differentiate from sibling tools like 'pay_lightning_invoice' or 'check_channel_balance', which prevents a score of 5.
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., needing a wallet or balance), use cases (e.g., for paid data vs. free endpoints), or exclusions (e.g., not for direct payments). With sibling tools like 'pay_lightning_invoice' and 'get_agent_balance', this lack of context is a significant gap.
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 implies a write operation ('Create') but doesn't specify if this is idempotent, requires authentication, has rate limits, or what happens on failure (e.g., network issues). For a financial tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.
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 that directly states the tool's purpose without any fluff or redundancy. It is appropriately sized and front-loaded, with every word contributing to clarity. No wasted space or 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?
Given the complexity of a financial invoice creation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., invoice string, expiry time), error conditions, or dependencies like wallet availability. For this context, more detail is needed to adequately guide an agent.
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 three parameters (amount_sats, description, agent). The description adds no additional parameter semantics beyond what's in the schema, such as explaining the relationship between amount_sats and Bitcoin units or when to use the optional agent parameter. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('Lightning Network invoice') with the purpose 'to receive Bitcoin payments'. It distinguishes from siblings like 'pay_lightning_invoice' (sending) and 'decode_invoice' (reading), but doesn't explicitly contrast with them. The purpose is specific and functional, though not maximally differentiated.
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 like 'send_to_lightning_address' or 'pay_lightning_invoice', nor does it mention prerequisites such as requiring an agent wallet setup. It states what the tool does but offers no contextual usage rules 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't mention any behavioral traits such as whether it's read-only, requires authentication, has rate limits, or what the return format might be. This is a significant gap for a tool that likely involves sensitive 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 that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
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 the balance represents (e.g., confirmed vs. unconfirmed), the return format, or any error conditions. This leaves the agent with insufficient information for reliable 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?
The input schema has 100% description coverage, with the single parameter 'agent_id' clearly documented as 'Agent wallet name or ID'. The description doesn't add any additional meaning beyond this, so it meets the baseline score of 3 where 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 action ('Get') and resource ('Bitcoin balance for an agent wallet'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'check_channel_balance' or 'get_transaction_history', which might also involve balance-related queries, so it misses the highest score.
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. For example, it doesn't specify if this is for checking on-chain balances versus Lightning balances, or how it differs from 'check_channel_balance' or 'get_transaction_history'. This lack of context leaves the agent without clear usage instructions.
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 for behavioral disclosure. While 'Get' implies a read-only operation, it doesn't specify whether this requires authentication, what format the history returns (e.g., chronological order, filtered by status), or any rate limits. The description is too minimal for a tool that presumably accesses 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 no wasted words. It's appropriately sized for a simple tool with one optional parameter 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 financial transaction tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'recent' means (time window?), what data fields are returned, or any authentication requirements. Given the context of Lightning payments and multiple sibling tools, 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%, with the single parameter 'max_payments' clearly documented in the schema. The description adds no additional parameter information beyond what's already in the structured schema, so it meets the baseline score when schema coverage is complete.
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') and resource ('Lightning payment history') with the qualifier 'recent' providing scope. However, it doesn't explicitly distinguish this tool from potential siblings like 'list_channels' or 'access_l402_api' which might also provide transaction-related data, so it doesn't reach the highest score.
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. With siblings like 'list_channels' and 'access_l402_api' that might overlap in functionality, there's no indication of when this specific tool is appropriate or what makes it different from other options.
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. While it states this is a payment operation (implying funds transfer), it doesn't describe what happens on failure, whether payments are reversible, what permissions are required, or any rate limits. The mention of 'agent wallet funds' hints at spending policy enforcement but doesn't elaborate on what that entails.
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 that conveys the core purpose without unnecessary words. It's appropriately sized for a tool with good schema documentation and gets straight to the point with no fluff or redundant 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?
For a payment tool with no annotations and no output schema, the description is minimally adequate. It identifies the core action and funding source but lacks important context about failure modes, return values, or operational constraints. The 100% schema coverage helps, but for a financial transaction tool, more behavioral context would be beneficial.
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 doesn't add any parameter-specific information beyond what's in the schema descriptions, maintaining the baseline score of 3 for adequate coverage through structured data alone.
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 ('Pay') and resource ('Lightning Network invoice') with the funding source ('agent wallet funds'), making the purpose immediately understandable. It doesn't explicitly distinguish from siblings like 'send_to_lightning_address' which might have overlapping functionality, but the specific mention of invoice payment provides good differentiation.
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 like 'send_to_lightning_address' or 'access_l402_api'. It mentions the funding source ('agent wallet funds') which implies a prerequisite of having wallet funds, but doesn't specify when this tool is appropriate versus other payment methods or what conditions must be met.
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 what the tool does but doesn't describe behavioral traits such as whether it requires authentication, has rate limits, returns real-time or cached data, or what happens on errors. For a tool with zero annotation coverage, this is a significant gap in 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 a single, efficient sentence that directly states the tool's function. It's front-loaded with the core purpose and includes specific details (outbound and inbound liquidity) without any wasted words. Every part of the sentence contributes meaning, making it optimally concise 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 complexity (simple read operation with no parameters) and the absence of annotations and output schema, the description is minimally complete. It tells what the tool does but lacks details on behavior, output format, or error handling. For a tool with no structured metadata, the description is adequate but leaves clear gaps in understanding how to use it effectively.
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 zero parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics since there are none. It appropriately focuses on the tool's purpose without unnecessary parameter details, earning a high baseline score for this dimension.
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: checking Lightning channel balance, specifying both outbound and inbound liquidity. It uses specific verbs ('check') and resources ('Lightning channel balance'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_channels' or 'get_agent_balance', which prevents 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 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 when this tool is appropriate, when not to use it, or how it differs from related tools like 'list_channels' or 'get_agent_balance'. This lack of contextual guidance leaves the agent to infer usage scenarios.
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 mentions 'owner access required', adding some behavioral context about permissions. However, it doesn't disclose critical traits like whether deletion is irreversible, what happens to associated data (e.g., balance, transactions), error conditions, or rate limits. For a destructive tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Delete an agent wallet') and includes essential details (identification method and access requirement). There is no wasted verbiage, making it highly concise and well-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?
Given the tool's complexity (destructive deletion), lack of annotations, and no output schema, the description is incomplete. It misses key details like the irreversible nature of deletion, what 'owner access' entails, potential side effects, and response format. For a tool with significant behavioral implications, this leaves gaps in understanding.
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 the parameter 'agent' documented as 'Agent wallet name or ID to delete'. The description adds no additional meaning beyond this, as it repeats the same information. According to rules, with high schema coverage (>80%), the baseline is 3 even with no param info in description.
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 ('Delete') and target resource ('agent wallet'), specifying it can be identified by 'name or ID'. It distinguishes from siblings like 'list_agent_wallets' or 'create_agent_wallet' by focusing on deletion. However, it doesn't explicitly contrast with other deletion-related tools (none exist in siblings), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'owner access required', which implies a usage context (i.e., when the user has ownership permissions). It doesn't provide explicit alternatives (e.g., when to use vs. other wallet operations) or exclusions, leaving some ambiguity. This is implied guidance but lacks depth.
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 retrieves information ('Get'), implying a read-only operation, but doesn't specify whether it requires authentication, has rate limits, returns real-time or cached data, or what format the output takes. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence earns its place by specifying what is being retrieved.
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 complexity (simple read operation with no parameters) and the lack of annotations and output schema, the description is minimally adequate. It states what the tool does but doesn't provide enough context about the output format, error conditions, or behavioral traits. For a tool with no structured output documentation, more detail on what 'info' includes would improve completeness.
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, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately avoids mentioning any. A baseline score of 4 is applied since no parameters exist, and the description doesn't introduce confusion about inputs.
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 ('Get') and resource ('Lightning node connection status and info'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'list_channels' or 'check_channel_balance', which might provide overlapping or related information about the Lightning network.
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. With sibling tools like 'list_channels', 'check_channel_balance', and 'get_agent_balance' available, there's no indication of whether this tool is for general node status, specific connection details, or how it differs from other informational tools in the set.
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 authentication context ('agent key: own wallet only'), which is useful, but lacks details on rate limits, pagination, error conditions, or what specific 'status' values mean. For a list operation with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.
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—a single sentence with a clarifying parenthetical. It's front-loaded with the core purpose and includes only essential context. Every word earns its place, with no 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 tool's complexity (a list operation with no parameters) and the absence of both annotations and an output schema, the description is minimally adequate. It covers what the tool does and hints at authentication context, but doesn't explain the return format (e.g., structure of balances/status) or potential limitations. This leaves the agent with incomplete information for proper 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 tool has 0 parameters, and schema description coverage is 100%. In such cases, the baseline score is 4, as there are no parameters to document. The description appropriately doesn't waste space on parameter details, focusing instead on the tool's purpose and context.
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: 'List all agent wallets with their balances and status'. It specifies the verb ('List') and resource ('agent wallets'), and includes scope details ('with their balances and status'). However, it doesn't explicitly differentiate from sibling tools like 'get_agent_balance' or 'check_channel_balance', which prevents 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 guidance through the parenthetical note 'agent key: own wallet only', suggesting this tool is for viewing one's own wallets when authenticated with an agent key. However, it doesn't explicitly state when to use this versus alternatives like 'get_agent_balance' or 'list_channels', nor does it provide clear exclusions or prerequisites.
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. While it mentions the protocol (LNURL-pay), it doesn't describe important behavioral aspects like whether this is a final payment (irreversible), what happens on failure, authentication requirements, rate limits, or what the response contains. For a payment tool with zero annotation coverage, this leaves significant gaps.
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 that conveys the essential information without any wasted words. It's appropriately sized for the tool's complexity and gets straight to the point.
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 payment tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after sending (success/failure response format), whether payments are reversible, authentication requirements, or error conditions. Given the tool's financial nature and lack of structured behavioral information, more context 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 four parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. This meets the baseline expectation when schema coverage is complete.
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 ('Send sats'), target resource ('to a Lightning address'), and protocol used ('using LNURL-pay protocol'). It distinguishes from sibling tools like 'pay_lightning_invoice' by specifying the Lightning address format rather than invoice-based payments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning Lightning addresses and LNURL-pay protocol, suggesting this is for sending payments via that specific method. However, it doesn't explicitly state when to use this versus alternatives like 'pay_lightning_invoice' or provide any exclusion criteria.
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, the description carries full burden but only states what data is returned without behavioral details. It lacks information on permissions, rate limits, pagination, or whether it's a read-only operation, which is critical for a listing tool.
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 that front-loads the purpose and key details. Every word contributes value, with no wasted text or redundancy, making it highly concise 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?
For a tool with 0 parameters and no output schema, the description is adequate but incomplete. It specifies what data is returned but lacks behavioral context (e.g., read-only nature, potential errors), which is needed given the absence of annotations and output schema.
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?
There are 0 parameters, and schema coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information.
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 verb ('List') and resource ('all Lightning channels') with specific attributes ('capacity, balance, and peer info'). It distinguishes from siblings like 'check_channel_balance' (single channel) and 'list_agent_wallets' (different resource).
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 is provided. It doesn't mention prerequisites, timing, or comparisons to siblings like 'get_node_info' or 'check_channel_balance', leaving the agent to infer usage context.
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 'owner access required' which is valuable context about authentication needs, but doesn't describe what happens after creation (e.g., whether the wallet is immediately usable, what data is returned, or if there are rate limits). For a creation tool with zero annotation coverage, this leaves significant behavioral aspects unspecified.
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 that communicates the core purpose and key constraint without any wasted words. It's appropriately sized for a tool with one parameter and no output schema, and the information is front-loaded with no 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 that this is a creation tool with no annotations and no output schema, the description should do more to explain what happens after creation. While it mentions the access requirement, it doesn't describe the creation outcome, return values, or potential side effects. The description is adequate but has clear gaps for a tool that creates a resource.
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 schema description coverage is 100%, so the schema already fully documents the single parameter 'agent_name'. The description doesn't add any parameter-specific information beyond what's in the schema, such as naming conventions or constraints. With complete 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.
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 new Bitcoin wallet') and the resource ('for an AI agent'), with the additional constraint 'owner access required' that distinguishes it from potential sibling tools like 'list_agent_wallets' or 'get_agent_balance' which don't require owner access. It uses precise language that leaves no ambiguity about what the tool does.
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 explicitly states 'owner access required', providing clear context about when this tool should be used (when the caller has owner privileges). However, it doesn't specify when NOT to use it or mention alternatives like 'list_agent_wallets' for viewing existing wallets, so it falls short of the highest score.
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 discloses the tool's purpose (inspection/decoding) and output fields (amount, expiry, destination), which is helpful. However, it doesn't mention behavioral aspects like error handling, rate limits, or authentication requirements, leaving gaps 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 a single, efficient sentence that front-loads the core purpose ('Decode a Lightning invoice') and adds essential context ('to inspect amount, expiry, destination before paying'). Every word earns its place with zero waste.
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 provides basic purpose and usage context but lacks details on return values, error cases, or system behavior. For a decoding tool with 1 parameter, it's minimally adequate but leaves significant gaps in 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%, with the single parameter 'invoice' well-documented in the schema as 'BOLT11 Lightning invoice to decode'. The description adds no additional parameter details beyond what the schema provides, so it meets the baseline of 3 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 specific action ('decode'), resource ('Lightning invoice'), and purpose ('to inspect amount, expiry, destination before paying'). It distinguishes from siblings like 'pay_lightning_invoice' by focusing on inspection rather than payment.
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?
Explicitly states when to use this tool: 'before paying' a Lightning invoice. This provides clear context for usage versus alternatives like 'pay_lightning_invoice' (for actual payment) or 'create_lightning_invoice' (for invoice creation).
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:

[![agentbtc-mcp MCP server](https://glama.ai/mcp/servers/bkblocksolutions-rgb/agentbtc-mcp/badges/card.svg)](https://glama.ai/mcp/servers/bkblocksolutions-rgb/agentbtc-mcp)

Score Badge

Copy to your README.md:

[![agentbtc-mcp MCP server](https://glama.ai/mcp/servers/bkblocksolutions-rgb/agentbtc-mcp/badges/score.svg)](https://glama.ai/mcp/servers/bkblocksolutions-rgb/agentbtc-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/bkblocksolutions-rgb/agentbtc-mcp'

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