Provides tools for Bitcoin key management, address generation, transaction building, script operations, and cryptography, interacting with the Bitcoin blockchain via the python-bitcoinlib API.
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., "@mcp-python-bitcoinlib Generate a new Bitcoin private key in WIF format"
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.
An MCP server that exposes the python-bitcoinlib API
pip install mcp-python-bitcoinlibRelated MCP server: Bitcoin-MCP-Server
mcp-python-bitcoinlibmcp-name: io.github.daedalus/mcp-python-bitcoinlib
Add to your claude_desktop_config.json:
{
"mcpServers": {
"mcp-python-bitcoinlib": {
"command": "mcp-python-bitcoinlib",
"env": {}
}
}
}The server exposes the following Bitcoin tools:
Key Management: Generate private keys, convert between WIF and hex
Address Generation: P2PKH, P2SH, P2WPKH, P2WSH addresses
Transaction Building: Create and sign transactions
Script Operations: Parse and create Bitcoin scripts
Cryptography: SHA256, RIPEMD160, Hash160, Hash256, ECDSA signing/verification
git clone https://github.com/daedalus/mcp-python-bitcoinlib.git
cd mcp-python-bitcoinlib
pip install -e ".[test]"
# run tests
pytest
# format
ruff format src/ tests/
# lint
ruff check src/ tests/
# type check
mcp-python-bitcoinlib src/Get the script from an address.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Bitcoin address. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility. It does not disclose address validation, error handling, or any side effects. Minimal 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?
Single sentence with no wasted words. Could be expanded slightly to add behavioral context without losing 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?
With an output schema present, explaining return values is not necessary. However, the description lacks behavioral details for a straightforward conversion tool. Adequate but not complete.
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 coverage is 100% with a single parameter described as 'Bitcoin address.' The description adds no further meaning, so baseline score of 3 applies.
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 'Get the script from an address.' clearly states the verb and resource, and distinguishes from sibling tools like parse_script or create_p2pkh_script. It could be more specific (e.g., what kind of script), but it's sufficiently clear.
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 on when to use this tool versus alternatives like parse_script or address conversion tools. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a P2PKH script from a public key hash.
| Name | Required | Description | Default |
|---|---|---|---|
| pubkey_hash | Yes | Public key hash as hex. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the creation action but does not disclose validation behavior, output format details, or any side effects.
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, front-loaded sentence with no unnecessary words, achieving maximum 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 existence of an output schema, return values are covered. However, with many sibling tools, the description could explain when P2PKH is appropriate, but it remains minimally adequate.
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 coverage is 100% for the single parameter, and the description aligns with it. However, the description adds little meaning beyond the parameter's name and type.
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 creates a P2PKH script from a public key hash, specifying the verb (Create), resource (P2PKH script), and input. This differentiates it from sibling tools like create_p2wpkh_script.
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 on when to use this tool versus alternatives is provided. The description does not mention context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a P2WPKH script from a public key hash.
| Name | Required | Description | Default |
|---|---|---|---|
| pubkey_hash | Yes | Public key hash as hex. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosure. It only says 'Create', implying a deterministic function, but does not detail state changes, permissions, or any side effects. For a simple script creation tool this is minimal but acceptable; however, it lacks explicit behavioral context.
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?
A single, front-loaded sentence with no unnecessary words. Every element (verb, resource, input) is essential and immediately clear.
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 (one parameter, output schema exists), the description is adequate. It explains what the tool does and the required input. However, it could briefly mention the output type or relate to sibling tools for better completeness.
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 coverage is 100% and the input schema already describes 'pubkey_hash' as a hex string. The description adds no extra meaning to the parameter, meeting the baseline of 3.
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 'Create', the resource 'P2WPKH script', and the input 'from a public key hash'. It effectively distinguishes this tool from siblings like 'create_p2pkh_script' (different script type) and 'address_to_script' (different input 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 such as 'create_p2pkh_script' or 'pubkey_to_address'. The description does not specify contexts, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an unsigned Bitcoin transaction.
| Name | Required | Description | Default |
|---|---|---|---|
| outputs | Yes | List of dicts with 'address' and 'satoshi' keys. | |
| fee | No | Transaction fee in satoshis (default: 1000). | |
| version | No | Transaction version (default: 2). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'unsigned' but doesn't disclose other behaviors such as whether it accepts inputs from other tools, what assumptions it makes about the network, or what happens if invalid addresses are provided. The output schema exists but is not shown.
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?
Extremely concise at one sentence, but too sparse. It could include a brief note on the output or usage context without becoming verbose.
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 complex domain with 19 sibling tools, the description is insufficient. It doesn't explain how this fits into the transaction lifecycle (e.g., need to add inputs, then sign/serialize), nor does it mention the return format or potential errors.
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 coverage is 100%, so the schema already describes each parameter. The description adds no extra meaning beyond what is in the schema, so a baseline of 3 is appropriate.
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 an unsigned Bitcoin transaction' clearly states the action (create) and the resource (unsigned Bitcoin transaction), and distinguishes it from siblings like sign_transaction and serialize_transaction.
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 on when to use this tool or prerequisites. For example, it doesn't mention that this tool likely requires inputs (UTXOs) to be specified elsewhere, or that the resulting unsigned transaction should be signed or serialized later.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a random private key and return it as a 32-byte hex string.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It clearly describes the generation of a random key and the output format, giving a solid understanding of the tool's behavior. No mention of randomness quality or cryptographic details, but sufficient.
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, well-structured sentence that is front-loaded with the key verb and resource. Every word contributes meaning, making it highly concise and efficient.
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?
The tool is simple with no parameters and an existing output schema. The description covers the essential aspects: no input required and the output is a 32-byte hex string. This is fully adequate for an agent to select and invoke the tool correctly.
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, and the input schema is empty with 100% coverage. The description effectively indicates that no input is needed, meeting the baseline for parameterless 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 action ('generate'), the resource ('a random private key'), and the output format ('32-byte hex string'). It effectively distinguishes itself from sibling tools like 'privkey_to_wif' or 'privkey_to_pubkey'.
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 implies usage when a new private key is needed, but it does not provide explicit guidance on when not to use it or mention alternatives. Given the sibling tools list, some context is implicit but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute Hash160 (SHA256 then RIPEMD160).
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Input data as hex string. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It describes the hashing algorithm but does not disclose traits like output format (hex string) or any side effects. For a simple pure computation, this is minimally adequate.
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 sentence with no unnecessary words. It is efficiently front-loaded with the verb and algorithm, making it concise and scannable.
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?
The tool is simple with one parameter and an output schema. The description covers the algorithm but omits explicit mention of the output format (hex-encoded hash). This is a minor gap that most agents would infer, so it is nearly complete.
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% for the single parameter, so the schema already documents the input as a hex string. The description adds no additional semantic meaning beyond what the schema provides, meeting the baseline.
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 computes Hash160, specifying it is SHA256 followed by RIPEMD160. It uses a specific verb 'Compute' and identifies the resource 'Hash160', distinguishing it from sibling hashing tools like sha256_hex and ripemd160_hex.
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 hash256_hex or ripemd160_hex. The description only explains what it does without any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute double SHA256.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Input data as hex string. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the basic operation without disclosing behavioral traits such as purity, side effects, or output format (though output schema exists). The description is insufficiently transparent.
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 (one sentence) and front-loaded. However, it sacrifices helpful detail for brevity.
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 simplicity of the tool (one well-known operation, one param, output schema present), the description is minimally adequate. But with sibling tools, more context would improve completeness.
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 coverage is 100% and the parameter description already states 'Input data as hex string.' The tool description adds no extra meaning beyond that. Baseline 3 is appropriate.
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 computes double SHA256, a well-known cryptographic hash. The verb 'compute' and specific hash name distinguish it from sibling tools like sha256_hex (single SHA256) and ripemd160_hex.
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 on when to use this tool versus alternatives. An AI agent would not know the difference between double SHA256 and other hash tools without additional context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a script into its opcodes.
| Name | Required | Description | Default |
|---|---|---|---|
| script_hex | Yes | Script as hex string. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the basic action but omits details like error handling for invalid hex or what constitutes valid input. The output schema partially compensates, but the description lacks behavioral depth.
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 sentence, highly concise with no redundant information. Every word is necessary, and it conveys the essential purpose without waste.
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 low complexity (1 parameter, output schema exists), the description is nearly complete. It explains the input and result clearly. One minor gap: it could mention that the output is a structured representation of opcodes, but the output schema likely covers this.
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 coverage is 100% with one parameter 'script_hex' described as 'Script as hex string.' The description does not add meaning beyond the schema, so baseline 3 is appropriate.
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 uses a specific verb ('Parse') and resource ('a script'), and clearly states the output ('its opcodes'). This distinguishes it from sibling tools like 'address_to_script' or 'create_p2pkh_script', which involve creation or conversion rather than parsing.
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 explicit when-to-use or alternatives are provided. The usage is implied from the name and description, but there is no guidance on when parsing a script is necessary or when to prefer other tools. The context is clear enough for a simple utility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the public key from a private key.
| Name | Required | Description | Default |
|---|---|---|---|
| privkey | Yes | Private key as a 32-byte hex string. | |
| compressed | No | Whether to produce a compressed public key (default: True). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral details. It fails to specify the output format (hex), whether validity checks are performed, or how the 'compressed' parameter affects the result. The agent is left guessing essential 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 concise sentence, front-loading the purpose. However, it could be slightly expanded with useful context without becoming verbose.
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 cryptographic nature and the presence of an output schema, the description lacks details about the return value (e.g., hex string length, compression implications). It is adequate but not complete for an agent to fully understand the tool's output.
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 coverage is 100%, so the schema already documents both parameters adequately. The description adds no additional meaning beyond the schema, meeting the baseline expectation.
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 function: converting a private key to its corresponding public key. It uses a specific verb ('Get') and resource ('public key'), and distinguishes itself from sibling tools like 'generate_private_key' or 'privkey_to_wif'.
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. There is no mention of prerequisites, edge cases, or when not to use it (e.g., for keys not in hex format).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a private key (hex) to WIF format.
| Name | Required | Description | Default |
|---|---|---|---|
| privkey | Yes | Private key as a 32-byte hex string. | |
| compressed | No | Whether to produce a compressed WIF (default: True). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden. It fails to disclose behavior for invalid inputs or the default value of the compressed parameter. The description is too sparse for a conversion 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 a single, concise sentence with the verb and primary object front-loaded. However, it could be slightly more detailed without sacrificing 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?
With an output schema present, the description need not detail return values. However, it lacks error handling or edge case information, which would be beneficial for a conversion tool.
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 coverage is 100% with descriptions for both parameters. The description adds no additional meaning beyond what the schema provides, meeting the baseline but not exceeding it.
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 (convert), input (private key hex), and output (WIF format), distinguishing it from sibling tools like wif_to_privkey and privkey_to_pubkey.
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, nor on the difference between compressed and uncompressed output. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a public key to an address.
| Name | Required | Description | Default |
|---|---|---|---|
| pubkey | Yes | Public key as a hex string (33 or 65 bytes). | |
| address_type | No | Address type - "p2pkh", "p2sh", "p2wpkh", or "p2wsh". | p2pkh |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 only states a basic transformation without mentioning error handling, supported public key formats in detail, or dependencies. The agent cannot anticipate failure modes or side effects.
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 sentence that gets straight to the point. It is front-loaded and efficient for a simple conversion tool, though a bit more context could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of many sibling tools and the lack of output schema details in the description, the minimal text leaves the agent ill-equipped to choose the correct address type or understand output structure. The description relies heavily on the schema and inferred knowledge.
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 already documents both parameters adequately. The description adds no additional semantic value 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 'Convert a public key to an address' clearly states the verb and resource, making the tool's purpose immediately apparent. It distinguishes from sibling tools like privkey_to_pubkey or address_to_script, though it does not explicitly differentiate 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 such as validate_address or address_to_script. It lacks context on prerequisites, preferred address types, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the P2SH-P2WPKH redeemScript for a public key.
| Name | Required | Description | Default |
|---|---|---|---|
| pubkey | Yes | Public key as a hex string. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 does not disclose any behavioral traits such as whether the tool is read-only, has side effects, or requires specific permissions. The description only states the function without any additional behavioral context.
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. It is appropriately front-loaded and concise for a simple tool. However, it could be slightly more informative while remaining concise.
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 simplicity of the tool (one parameter, straightforward output) and the existence of an output schema, the description is adequate for basic usage. However, it lacks usage guidelines and behavioral transparency, which are important for completeness. The presence of numerous sibling tools further underscores the need for more context.
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 coverage is 100% and the single parameter 'pubkey' is described as 'Public key as a hex string.' The description adds no extra meaning beyond what the schema already provides. Baseline 3 is appropriate as the schema does the heavy lifting, and no further semantic enrichment is needed.
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 and the resource: 'Get the P2SH-P2WPKH redeemScript for a public key.' It uses a specific verb and resource, and the output (redeemScript) is distinct from sibling tools like pubkey_to_address or create_p2wpkh_script. However, it does not explicitly differentiate itself from siblings that might also produce similar scripts.
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. The description does not mention prerequisites, when to choose this over other script-related tools, or any exclusion criteria. This leaves the agent with no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute RIPEMD160 hash.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Input data as hex string. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It states the action (compute hash) but does not detail side effects, determinism, or input/output constraints beyond what the schema provides. An output schema exists, which helps, but minor behavioral context is missing.
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—three words—and immediately conveys the tool's purpose. Every word earns its place with no unnecessary content.
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, parameter count of 1, and the presence of an output schema, the description provides adequate context. It could optionally mention the output format, but completeness is high for a straightforward hash function.
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 covers 100% of parameters and already describes 'data' as a hex string. The description adds no additional semantic value beyond the schema, earning a baseline score of 3.
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 'Compute RIPEMD160 hash' uses a specific verb and resource, clearly stating the tool's function. It distinguishes well from sibling tools like sha256_hex and hash160_hex, which compute different hashes.
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 hash160_hex or sha256_hex. There is no mention of use cases, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Serialize and deserialize a transaction.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hex | Yes | Transaction as hex string. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description provides no behavioral details such as side effects, error conditions, or output format. The tool's behavior beyond the basic function is opaque.
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 very short (one sentence) but sacrifices necessary detail. It is concise but not effective, as it omits crucial information about directionality.
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 transaction serialization, the description is incomplete. It does not leverage the output schema's existence or provide enough context for an agent to use it correctly.
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 coverage is 100%, with the parameter 'tx_hex' described as 'Transaction as hex string.' The tool description adds no additional semantic meaning beyond what is in the schema.
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 states 'Serialize and deserialize a transaction,' which gives a general purpose but is vague. It does not specify whether the tool converts from hex to a structured format or vice versa, or if it handles both directions based on input. This ambiguity reduces clarity.
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 over siblings like create_transaction or sign_transaction. There is no differentiation or context about typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute SHA256 hash.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Input data as hex string. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'Compute SHA256 hash,' omitting details like determinism, output format, or that it is a pure function. For a simple cryptographic hash, this is minimal but not misleading.
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 sentence with no fluff, but it is so short that it sacrifices clarity and completeness. Conciseness is good, but under-specification reduces its effectiveness.
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 simplicity (1 param, common algorithm), the description is adequate but fails to differentiate from siblings like hash160_hex. It does not mention the output format, though an output schema likely exists. Leaves room for confusion.
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%, and the schema already describes the parameter 'data' as 'Input data as hex string.' The description adds no semantic value beyond the schema, so baseline score of 3 is appropriate.
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 algorithm (SHA256) and the action (compute hash), distinguishing it from siblings like hash256_hex (double SHA256) and ripemd160_hex. However, it does not mention that the input is a hex string, which is only available in the schema.
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 on when to use this tool versus alternatives. With 19 sibling tools including other hashing algorithms, the description offers no 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 a private key.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Message to sign. | |
| privkey | Yes | Private key as hex. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose important behavioral traits such as output format, error cases, or security implications of handling private keys.
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 very short and could benefit from more detail without being excessively verbose.
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?
With 19 sibling tools and a sensitive operation (private key handling), the description is too minimal and lacks warnings or return value details.
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 coverage is 100%, describing both parameters well. The description adds no additional meaning beyond the schema.
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 it signs a message with a private key, distinguishing it from sibling tools like sign_transaction which signs transactions.
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 on when to use this tool versus alternatives like sign_transaction or verify_signature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sign a transaction input with a private key.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hex | Yes | Transaction as hex string. | |
| privkey | Yes | Private key as hex string. | |
| sighash_type | No | Sighash type (default: 1 = SIGHASH_ALL). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'Sign a transaction input with a private key,' omitting details on side effects, return value, security implications, or limitations (e.g., whether it modifies the original transaction).
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 terse sentence with no wasted words. While it lacks detail, it is concise and front-loads the core 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 signing transactions (3 parameters, output schema exists), the description is insufficient. It does not explain input/output formats, default values, or error conditions, making it inadequate for an agent to use correctly without external context.
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 coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema; it does not explain the hex format of `tx_hex` and `privkey` or the significance of `sighash_type` options.
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 (transaction input with a private key). It differentiates from sibling tools like `verify_signature` and `sign_message` by specifying 'transaction input'. However, it does not explicitly contrast with `sign_message`, so clarity is high but not perfect.
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 on when to use this tool versus alternatives (e.g., `sign_message` or `verify_signature`). The description only states what it does, not when it is appropriate or what prerequisites are required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a Bitcoin address for a given network.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Bitcoin address to validate. | |
| network | No | Network name - "main", "testnet", "signet" (default: "main"). | main |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must fully disclose behavior. It only says 'validate' without explaining what validation entails (format, checksum, network match) or the output format. Users cannot infer side effects or failure modes.
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?
Single sentence, no fluff. Could be more detailed but remains efficient.
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?
Despite low complexity and existing output schema, the description fails to explain what validation means or what the tool returns. A user would need to infer from the name alone.
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 parameters are already documented. Description adds minimal value beyond 'for a given network', which is already in the schema.
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?
Description clearly states the tool validates a Bitcoin address with a network parameter, distinguishing it from sibling tools that create, convert, or hash addresses.
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 on when to use this tool versus alternatives like pubkey_to_address or address_to_script. No exclusion criteria or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an ECDSA signature.
| Name | Required | Description | Default |
|---|---|---|---|
| signature | Yes | Signature as hex. | |
| pubkey | Yes | Public key as hex. | |
| message | Yes | Message that was signed. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states the basic function without specifying the output (boolean? success/error?), edge cases, or error conditions.
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 (one sentence), which is positive for a simple tool. However, it lacks structure and could include more information without becoming verbose.
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 and the presence of an output schema (not shown), the description still feels incomplete. It omits usage context, behavioral info, and any distinction from similar tools.
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 each parameter having a brief description. The tool description does not add any extra meaning beyond what is already in the schema, so baseline score of 3 is appropriate.
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 (verify) and the resource (ECDSA signature), specifically distinguishing it from sibling tools like sign_message which creates signatures.
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 on when to use this tool versus alternatives (e.g., sign_message) or what prerequisites are needed (e.g., correct message format). The context signals show many sibling tools but the description offers no differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a WIF-encoded private key back to hex.
| Name | Required | Description | Default |
|---|---|---|---|
| wif | Yes | WIF-encoded private key. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden of behavioral disclosure. It only states conversion, missing details like input validation, error handling, or that it decodes Base58. For a simple tool, more transparency is expected.
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. It is appropriately front-loaded and concise 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, the description covers the basic purpose. However, it could mention that it is the inverse of 'privkey_to_wif' or specify the output format. The presence of an output schema mitigates some need, but more context would improve completeness.
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 coverage is 100%, with the parameter description already provided. The tool description adds no extra meaning beyond what is in the schema, so baseline score of 3 is appropriate.
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 'Convert' and the resource 'WIF-encoded private key' to output 'hex'. It is specific and distinguishes itself from the sibling tool 'privkey_to_wif' which performs the reverse operation.
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 implies usage when you have a WIF key and need hex, but does not explicitly state when to use versus alternatives. Since it is a straightforward conversion, the implied context is sufficient, but explicit guidance would improve this score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0address_to_scriptcreate_p2pkh_scriptcreate_p2wpkh_scriptcreate_transactiongenerate_private_keyhash160_hexhash256_hexparse_scriptprivkey_to_pubkeyprivkey_to_wifpubkey_to_addresspubkey_to_p2sh_p2wpkh_redeemscriptripemd160_hexserialize_transactionsha256_hexsign_messagesign_transactionvalidate_addressverify_signaturewif_to_privkeyEach tool has a clearly distinct purpose: hashing functions target specific algorithms, key operations are separated, address and script creation focus on different types, and transaction operations are distinct from signing. No two tools overlap in functionality.
All tools use consistent snake_case naming with a verb-noun pattern (e.g., create_p2pkh_script, sign_transaction). Hash functions follow a uniform 'algorithm_hex' pattern. No mixing of conventions or ambiguous names.
With 20 tools, the server covers essential Bitcoin operations without being bloated. Each tool serves a specific need, from key generation and address conversion to transaction creation and signing. The count is appropriate for a comprehensive Bitcoin library.
The tool set covers major Bitcoin workflows: key management, address generation (P2PKH, P2WPKH, P2SH-P2WPKH), transaction creation and signing, message signing, hashing, and validation. Minor gaps like explicit bech32 address or multisig script creation are absent but non-critical for most use cases.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server with quote and live cryptocurrency price tools, local and cloud-deployed transports.
MCP server for developer documentation, generated by doc2mcp.
MCP server for doc2mcp documentation, generated by doc2mcp.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/daedalus/mcp-python-bitcoinlib'
If you have feedback or need assistance with the MCP directory API, please join our Discord server