Enables management of Bitcoin on-chain transactions including generating addresses, sending Bitcoin, and listing transaction history through RGB Lightning Node APIs.
Provides Lightning Network operations including creating and paying invoices, managing channels, and handling RGB asset transfers over the Lightning Network.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@RGB Lightning Network MCP Server what's my RGB asset balance?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides integration with RGB Lightning Node APIs. This server enables AI assistants to interact with RGB assets, Lightning Network operations, and Bitcoin on-chain transactions.
Node Operations: Check node status, get network information
RGB Asset Management: List assets, check balances, send RGB assets
Lightning Network: Create/pay invoices, manage channels
On-chain Transactions: Generate addresses, send Bitcoin, list transactions
Swap Operations: List and manage asset swaps
Related MCP server: Alby Bitcoin Payments MCP Server
You can use this server directly with MCP clients like Cursor, Claude Desktop, Trae, or Cherry Studio by running
Note: Please replace with your RGB api key: xxxxxxxxxxxxxxxxxxxx Or /path/rgbapi.key
Add this configuration to your MCP client (e.g., Claude Desktop config):
{
"mcpServers": {
"rgb-mcp-server": {
"command": "npx",
"args": [
"-y",
"rgb-mcp-server"
],
"env": {
"RGB_API_BASE_URL": "http://localhost:3000",
"RGB_API_KEY": "xxxxxxxxxxxxxxxxxxxx" //Optional: RGB api key Or /path/rgbapi.key
}
}
}
}For developers who want to contribute or use this project:
Make sure you have Node.js installed (version 16 or higher recommended)
Install dependencies:
npm install rgb-mcp-serverAfter installing the package, you can use it programmatically in your Node.js application:
import { getRGBMcpServer } from "rgb-mcp-server";
// Initialize the RGB MCP server
const rgbMcpServer = await getRGBMcpServer({
baseUrl: process.env.RGB_API_BASE_URL || 'http://localhost:3000', // RGB API server URL
apiKey: process.env.RGB_API_KEY, // Optional: API key for authentication
timeout: 30000 // Optional: request timeout in ms
});
// Access available tools
const rgbTools = rgbMcpServer._registeredTools;
console.log('Available RGB tools:', Object.keys(rgbTools));The server provides the following MCP tools:
rgb_get_node_info - Get RGB node information
rgb_get_node_status - Get node status and uptime
rgb_list_assets - List all RGB assets
rgb_get_asset_balance - Get balance for a specific asset
rgb_send_asset - Send RGB assets
rgb_generate_address - Generate new on-chain address
rgb_list_transactions - List on-chain transactions
rgb_send_bitcoin - Send Bitcoin to an address
rgb_create_lightning_invoice - Create Lightning invoice
rgb_pay_lightning_invoice - Pay Lightning invoice
rgb_list_lightning_channels - List Lightning channels
rgb_list_swaps - List available swaps
rgb_create_swap - Create a new asset swap
MIT
Check if an indexer URL is valid
| Name | Required | Description | Default |
|---|---|---|---|
| indexerUrl | Yes | The indexer URL to check |
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 indexer URL is valid,' implying a read-only validation operation, but doesn't detail what 'valid' means (e.g., format, connectivity, authentication), potential side effects, or error handling. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without any fluff or redundancy. It is front-loaded and efficiently communicates the core function, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'valid' entails, the return format (e.g., boolean, status details), or error conditions. For a validation tool with no structured behavioral data, this leaves critical gaps in understanding how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 'indexerUrl' documented as 'The indexer URL to check.' The description adds no additional meaning beyond this, such as examples or constraints. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema already provides adequate parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('indexer URL'), making it immediately understandable. However, it doesn't differentiate this validation tool from its siblings (like rgb_get_node_info or rgb_get_network_info), which also retrieve information but about different resources, so it misses the highest mark for sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as needing a valid indexer URL format, or compare it to siblings like rgb_get_node_info for broader system checks. This lack of context leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Lightning Network invoice
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount in satoshis | |
| description | No | Invoice description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose whether this requires authentication, has rate limits, returns a specific invoice format (e.g., bolt11), or if the invoice expires. For a creation tool with zero annotation coverage, this leaves critical operational traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by directly conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of creating a Lightning invoice (involving network operations and financial transactions), no annotations, and no output schema, the description is insufficient. It lacks details on return values (e.g., invoice string, expiry), error conditions, or integration context, leaving the agent under-informed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema (amount in satoshis, invoice description). The tool description adds no additional parameter semantics beyond what the schema provides, such as example values or constraints. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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'), making the purpose immediately understandable. It distinguishes from siblings like rgb_pay_lightning_invoice (which pays invoices) and rgb_decode_lightning_invoice (which decodes them). However, it doesn't specify what type of invoice or for what context, 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.
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 Lightning node setup), compare to rgb_create_swap (which might involve invoices), or indicate scenarios like receiving payments versus testing. Without any usage context, the agent must infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new asset swap
| Name | Required | Description | Default |
|---|---|---|---|
| swapParams | Yes | Swap parameters object |
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 only states the action 'create' without detailing permissions, side effects, error conditions, or response format. For a tool that likely involves financial transactions, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of asset swaps, lack of annotations, and no output schema, the description is incomplete. It fails to explain what an asset swap is, its implications, or what the tool returns, leaving critical gaps for an agent to understand and use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'swapParams' documented as a 'Swap parameters object'. The description does not add any meaning beyond this, such as explaining what swap parameters include or providing examples. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new asset swap' restates the tool name 'rgb_create_swap' with minimal elaboration, making it tautological. It specifies the verb 'create' and resource 'asset swap' but lacks detail on what an asset swap entails or how it differs from sibling tools like rgb_send_assets or rgb_list_swaps, leaving the purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as rgb_send_assets or rgb_list_swaps. The description does not mention prerequisites, context, or exclusions, offering no help for an agent to decide between tools in this financial/asset management domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode an RGB Lightning invoice
| Name | Required | Description | Default |
|---|---|---|---|
| invoice | Yes | The RGB Lightning invoice to decode |
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 but offers minimal information. It states what the tool does ('Decode') but doesn't describe the decoding process, output format, error handling, or any side effects (e.g., network calls, validation). For a tool with no annotation coverage, this is inadequate, as it leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words, making it highly concise and front-loaded. It immediately conveys the core function without unnecessary elaboration, which is efficient for an agent's quick comprehension. Every word earns its place by stating the essential action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (involving decoding of a specialized invoice format), lack of annotations, and no output schema, the description is insufficiently complete. It doesn't explain what decoding returns (e.g., structured data, validation result), potential errors, or how it integrates with sibling tools like payment or creation. For a tool with no structured output documentation, more descriptive context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'invoice' parameter clearly documented as 'The RGB Lightning invoice to decode'. The description adds no additional semantic context beyond this, such as invoice format examples or validation rules. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema does the heavy lifting without description enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Decode') and the resource ('RGB Lightning invoice'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'rgb_pay_lightning_invoice' or 'rgb_create_lightning_invoice' by focusing on decoding rather than creation or payment. However, it doesn't specify what decoding entails (e.g., extracting payment details, validating structure), 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.
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 valid invoice), contrast with similar tools like 'rgb_check_indexer_url' for validation, or indicate scenarios where decoding is necessary (e.g., before payment or for auditing). This lack of context leaves the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a new on-chain address
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 'generate a new on-chain address' but doesn't clarify if this is a read-only operation, if it requires authentication, what network it applies to, or if there are rate limits. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it highly concise and front-loaded. It directly communicates the core action without unnecessary elaboration, which is efficient for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of blockchain address generation, the lack of annotations and output schema means the description is incomplete. It doesn't explain what the generated address is for (e.g., RGB assets, Bitcoin), the format of the output, or any prerequisites, leaving the agent with insufficient context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 doesn't add parameter details, which is appropriate here, but it could briefly mention that no inputs are required. Baseline is 4 for 0 parameters, as the schema fully covers the absence of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'generate' and the resource 'new on-chain address', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'rgb_send_bitcoin' or 'rgb_send_assets' which might also involve addresses, leaving room for improvement in sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as whether it's for receiving assets versus sending, or if it's specific to certain asset types. Without any context or exclusions, the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get balance for a specific RGB asset
| Name | Required | Description | Default |
|---|---|---|---|
| assetId | Yes | The ID of the RGB asset |
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 'Get balance' implies a read operation, it doesn't specify whether this requires authentication, has rate limits, returns real-time vs cached data, or what format the balance comes in. This leaves significant behavioral gaps for a tool that presumably interacts with financial assets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - a single sentence that states exactly what the tool does without any unnecessary words. It's front-loaded with the core purpose and wastes no space on redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial balance tool with no annotations and no output schema, the description is insufficient. It doesn't explain what format the balance returns (numeric, string, structured object), what units it uses, whether it includes pending transactions, or any error conditions. Given the complexity of asset balance queries, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, with the single parameter 'assetId' clearly documented as 'The ID of the RGB asset.' The description doesn't add any additional parameter context beyond what the schema provides, so it meets the baseline for adequate but not exceptional parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get balance') and target resource ('for a specific RGB asset'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential alternatives like 'rgb_list_assets' or 'rgb_get_asset_metadata' which might provide related information, keeping it from 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.
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, timing considerations, or how it differs from sibling tools like 'rgb_list_assets' or 'rgb_get_asset_metadata' that might provide related asset information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata for a specific RGB asset
| Name | Required | Description | Default |
|---|---|---|---|
| assetId | Yes | The ID of the RGB asset |
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 it's a 'Get' operation, implying read-only behavior, but doesn't mention any traits like permissions needed, rate limits, error conditions, or what the metadata includes (e.g., asset details, ownership info). This leaves significant 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.
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 wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of asset metadata retrieval, no annotations, and no output schema, the description is incomplete. It doesn't explain what metadata is returned (e.g., asset properties, issuance details), potential errors, or how it differs from other asset-related tools, leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'assetId' clearly documented as 'The ID of the RGB asset'. The description adds no additional meaning beyond this, such as format examples or constraints, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'metadata for a specific RGB asset', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'rgb_get_asset_balance' or 'rgb_list_assets', which also retrieve asset-related information but with different scopes or data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 specify if this is for detailed metadata of a single asset, as opposed to listing assets or checking balances, leaving the agent to infer usage from the name alone without explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get network information from the RGB node
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention if this is a read-only operation, requires authentication, has rate limits, or what the output format might be, leaving significant gaps 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loading the purpose. It's appropriately sized for a simple tool with no parameters, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 that likely returns structured network data. It doesn't explain what 'network information' includes (e.g., connections, peers, status) or the response format, leaving the agent uncertain about behavior and outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 no parameter information is needed. The description doesn't add param details, but that's appropriate here, meeting the baseline for a zero-param tool without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('network information from the RGB node'), making the purpose understandable. It distinguishes from siblings like rgb_get_node_info and rgb_get_node_status by specifying 'network' information, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 rgb_get_node_info or rgb_get_node_status. It lacks any context about prerequisites, timing, or comparisons to sibling tools, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get RGB node information including ID, version, and network status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states it's a 'Get' operation, implying read-only behavior, but doesn't disclose any behavioral traits such as error conditions, rate limits, authentication needs, or what happens if the node is unavailable. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose ('Get RGB node information') and specifies key details. There is no wasted text, and it is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 states what information is retrieved, but lacks details on behavioral aspects and usage context, making it incomplete for fully informed tool selection by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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%, so no parameter documentation is needed. The description doesn't add param info beyond the schema, but with no parameters, this is acceptable, aligning with the baseline expectation for zero-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'RGB node information', specifying what information is retrieved (ID, version, network status). It distinguishes from some siblings like 'rgb_get_network_info' by focusing on node-specific details, though it doesn't explicitly differentiate from 'rgb_get_node_status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate compared to siblings like 'rgb_get_node_status' or 'rgb_get_network_info', nor does it specify any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get RGB node status and uptime information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. While 'Get' implies a read-only operation, the description doesn't specify whether this requires authentication, has rate limits, returns real-time vs cached data, or what format the status information takes. For a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise at 7 words, front-loading the core purpose without unnecessary elaboration. Every word earns its place, and there's zero waste or redundancy. This is an excellent example of efficient documentation for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is minimally adequate but could be more complete. While it states what information is retrieved, it doesn't clarify the scope (e.g., current node vs historical uptime) or format of the returned data. For a status-checking tool with no structured output documentation, additional context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema fully documents the parameter situation. The description appropriately doesn't waste space discussing nonexistent parameters. A baseline of 4 is appropriate since there are no parameters to document beyond what the schema already indicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('RGB node status and uptime information'), making it immediately understandable. However, it doesn't distinguish this tool from its sibling 'rgb_get_node_info', which appears to be a similar status/information retrieval tool, 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.
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 'rgb_get_node_info' and 'rgb_get_network_info' that likely retrieve related information, the agent must guess which tool is appropriate for specific status queries. No explicit when/when-not instructions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all RGB assets available in the node
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states it 'List all RGB assets' but doesn't disclose behavioral traits like whether it returns a paginated list, requires authentication, has rate limits, or what format the output takes. 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.
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 with no wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'all RGB assets' entails (e.g., format, scope, or limitations), leaving gaps in understanding for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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%, so there are no parameters to document. The description doesn't need to add parameter semantics, earning a baseline 4 as it appropriately omits unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('RGB assets available in the node'), making the purpose specific and understandable. It doesn't explicitly distinguish from siblings like 'rgb_get_asset_balance' or 'rgb_get_asset_metadata', which could provide more targeted asset information, so it doesn't reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention if this is for a broad overview versus using 'rgb_get_asset_balance' for specific asset details, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Lightning Network channels
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 but only states the action without details. It doesn't cover aspects like whether this is a read-only operation, potential rate limits, authentication needs, or what the output format might be (e.g., list structure, pagination). This leaves significant gaps for a tool that likely interacts with network data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste—it directly states the tool's function without unnecessary words. It's front-loaded and efficiently communicates the core purpose, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is minimally adequate but lacks depth. It doesn't explain what 'list' entails (e.g., format, scope like active vs. all channels) or behavioral traits, which could be important for Lightning Network operations. With no annotations to fill gaps, the description should do more to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 doesn't add parameter details, which is appropriate here, but it also doesn't explicitly state there are no parameters (e.g., 'with no filters'), slightly missing an opportunity for clarity. Baseline is 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('Lightning Network channels'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'rgb_list_assets' or 'rgb_list_swaps' beyond the resource name, 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.
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. There's no mention of prerequisites, context for listing channels (e.g., for monitoring or selection), or comparison to other list tools like 'rgb_list_assets', leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available swaps
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 'List available swaps', implying a read-only operation, but does not specify if it requires authentication, has rate limits, returns paginated results, or what 'available' means (e.g., pending vs. completed). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with 'List available swaps', a single phrase that is front-loaded and wastes no words. It efficiently conveys the core action without unnecessary elaboration, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 minimal but insufficient. It does not explain what 'swaps' are, the return format, or behavioral aspects like safety or constraints. For a list operation among many siblings, more context is needed to ensure proper usage, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 does not add parameter details, but since there are no parameters, this is acceptable. A baseline of 4 is appropriate as the schema fully covers the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List available swaps' clearly states the verb ('List') and resource ('swaps'), making the purpose understandable. However, it lacks specificity about what 'swaps' are in this context (e.g., asset swaps, lightning swaps) and does not differentiate from sibling tools like 'rgb_list_assets' or 'rgb_list_transactions', leaving ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 does not mention prerequisites, context (e.g., after creating a swap), or exclusions, and with siblings like 'rgb_list_assets' and 'rgb_list_transactions', the agent has no explicit direction on selecting this tool for 'swaps' specifically.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List on-chain transactions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. 'List on-chain transactions' implies a read-only operation but doesn't specify critical details like whether it requires authentication, returns paginated results, includes filtering options, or has rate limits. For a tool with zero annotation coverage, this leaves important behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('List on-chain transactions') that front-loads the core purpose without unnecessary words. It earns its place by clearly stating what the tool does in minimal language, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns complex transaction data. It doesn't explain what 'on-chain transactions' entails (e.g., format, scope, or limitations), leaving the agent with insufficient context to understand the tool's behavior fully. This is inadequate for a tool with no structured support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 absence of inputs. The description doesn't need to add parameter semantics, and it correctly avoids mentioning any parameters. A baseline of 4 is appropriate since no parameter information is required beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List on-chain transactions' clearly states the verb ('List') and resource ('on-chain transactions'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'rgb_list_assets' or 'rgb_list_swaps' beyond specifying the transaction type, 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.
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 'rgb_list_assets' and 'rgb_list_swaps' available, there's no indication of whether this tool is for general transaction listing, specific asset-related transactions, or other contexts. The lack of usage 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.
Pay a Lightning Network invoice
| Name | Required | Description | Default |
|---|---|---|---|
| bolt11 | Yes | BOLT11 invoice string |
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 action ('Pay') but lacks critical details: it doesn't specify if this is a destructive/mutative operation (likely yes, but unconfirmed), what permissions or authentication are required, potential rate limits, error conditions, or what happens upon success (e.g., transaction confirmation). This leaves significant gaps for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It is front-loaded with the core action ('Pay') and resource, making it immediately scannable and efficient for an agent to parse, which is ideal for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a payment operation (likely mutative and financial), the lack of annotations and output schema, and the description's minimalism, this is incomplete. The description doesn't cover behavioral traits, error handling, or return values, leaving the agent under-informed for a tool that could involve fund transfers and network interactions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'bolt11' parameter fully documented as a 'BOLT11 invoice string'. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or validation rules. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Pay') and the resource ('a Lightning Network invoice'), making the purpose immediately understandable. It distinguishes from siblings like 'rgb_create_lightning_invoice' (creation vs. payment) and 'rgb_send_assets' (asset transfer vs. invoice payment), though it doesn't explicitly mention these distinctions in the description itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 funded wallet), exclusions (e.g., invalid or expired invoices), or related tools like 'rgb_decode_lightning_invoice' for verification, leaving the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send RGB assets to recipients
| Name | Required | Description | Default |
|---|---|---|---|
| recipientMap | Yes | Map of asset IDs to recipient/amount pairs |
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 'Send RGB assets' which implies a write/mutation operation, but fails to mention critical details like transaction finality, confirmation requirements, error handling, or rate limits. This is inadequate for a tool that likely involves irreversible transfers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just four words, front-loading the core purpose without any wasted text. Every word earns its place, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of sending assets (a mutation with financial implications), no annotations, and no output schema, the description is insufficient. It lacks details on behavior, error cases, return values, and differentiation from siblings, leaving the agent with significant gaps in understanding how to use this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents the single parameter 'recipientMap'. The description adds no additional meaning about parameters beyond what the schema provides, such as format examples or constraints. 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.
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 ('RGB assets to recipients'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'rgb_send_bitcoin', which also sends assets but of a different type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'rgb_send_bitcoin' or 'rgb_pay_lightning_invoice'. The description lacks context about prerequisites, such as needing asset balances or network connectivity, which is a significant gap for a financial transaction tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send Bitcoin to an address
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | The recipient Bitcoin address | |
| amount | Yes | The amount to send in satoshis |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention whether this is a read/write operation, permission requirements, transaction finality, fee implications, rate limits, or error conditions, leaving significant gaps for a financial transaction tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the tool's purpose. There's no unnecessary information or repetition, making it front-loaded and efficient. Every word earns its place in this minimal but clear statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a Bitcoin sending tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after sending (transaction ID, confirmation status, error handling), nor does it address security implications or typical workflow context. The combination of missing behavioral transparency and output information creates significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters. The description adds no additional meaning beyond what's in the schema, such as address format validation or satoshi conversion details. With high schema coverage, the baseline score of 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.
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 ('Bitcoin'), specifying what the tool does. It distinguishes from siblings like 'rgb_send_assets' by focusing on Bitcoin specifically, but doesn't explicitly contrast with 'rgb_pay_lightning_invoice' which also involves Bitcoin transfers, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'rgb_send_assets' for other assets or 'rgb_pay_lightning_invoice' for Lightning payments. There's no mention of prerequisites, network conditions, or typical use cases, offering minimal context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sign a message with the RGB node
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The message to sign |
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 signing but doesn't clarify if this is a read-only operation, what cryptographic algorithm is used, whether it requires specific permissions, or what the output format is (e.g., a signature string). For a cryptographic tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action ('Sign a message') and includes essential context ('with the RGB node'). Every part of the sentence earns its place by specifying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of cryptographic signing, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a signature), potential errors, or security implications. For a tool that likely produces a critical output for blockchain operations, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'message' parameter clearly documented as 'The message to sign'. The description doesn't add any extra semantic context beyond this (e.g., format constraints or examples). According to the rules, with high schema coverage, the baseline is 3 even without additional param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Sign') and the resource ('a message'), specifying it's done 'with the RGB node'. It distinguishes from siblings like rgb_send_assets or rgb_pay_lightning_invoice by focusing on cryptographic signing rather than asset transfers or payments. However, it doesn't explicitly differentiate from all siblings (e.g., rgb_decode_lightning_invoice also involves message processing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an initialized RGB node), exclusions, or related tools like rgb_send_assets for signed transactions. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have clearly distinct purposes, such as creating invoices vs. paying them, or getting asset metadata vs. listing assets. However, rgb_get_node_info and rgb_get_node_status could be confused as both relate to node status, though their descriptions differentiate them slightly (info includes ID/version, status focuses on uptime).
All tool names follow a consistent verb_noun pattern with the 'rgb_' prefix, such as rgb_create_lightning_invoice and rgb_list_assets. The naming is uniform across all tools, using snake_case and clear action-object pairs, making it predictable and easy to understand.
With 18 tools, the count is slightly high but reasonable for a server covering RGB assets, Lightning Network, and swaps. It provides comprehensive coverage without being overwhelming, though it borders on the heavy side for typical MCP scopes.
The tool set offers complete coverage for the RGB and Lightning Network domain, including asset management (create, send, balance, metadata), network operations (invoices, channels, payments), and swaps. There are no obvious gaps; it supports full lifecycle operations from creation to transactions.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Non-custodial crypto payments for AI assistants: balances, payments, and create payment links.
Bitcoin and YouTube video intelligence for AI agents. Pay-per-call via x402 USDC on Base.
Provide AI agents and automation tools with contextual access to blockchain data including balance…
Collaboration layer for AI agents. Publish assets, send messages, manage threads and contacts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lnfi-network/rgb-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
