Used as the runtime environment for the MCP server, providing fast JavaScript execution for the wallet implementation
Enables deposits via Lightning invoices and payment of Lightning invoices through the wallet interface
Allows installation and execution of the MCP server through npm commands and package management
Integrates with Square's Goose AI assistant through configuration in Goose's config.yaml file
Click on "Deploy 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 Money what's my current balance across all mints?"
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 (Model Context Protocol) money implementation for Nostr using NDK (Nostr Development Kit) with Cashu ecash functionality.
Cashu Wallet Integration: Full support for Cashu ecash mints and tokens
Lightning Network: Deposit via Lightning invoices and pay Lightning invoices
Nostr Zaps: Send zaps to users using npub or NIP-05 identifiers
Multi-mint Support: Manage multiple Cashu mints simultaneously
Persistent Storage: Wallet state saved to local file with mint info caching
MCP Server: Expose wallet functionality through Model Context Protocol
CLI Interface: Direct command-line usage for all wallet operations
Related MCP server: Monei MCP Server
npm install mcp-moneyRun without arguments to start the MCP server:
npx mcp-moneyUse specific commands for direct wallet operations:
# Get total balance
npx mcp-money get_balance
# Get balance per mint
npx mcp-money get_mint_balances
# Create deposit invoice
npx mcp-money deposit 1000 https://testnut.cashu.space
# Pay lightning invoice
npx mcp-money pay lnbc1...
# Send a zap
npx mcp-money zap npub1... 100 "Great post!"
# Add a new mint
npx mcp-money add_mint https://mint.example.comThe wallet supports multiple ways to provide your Nostr private key:
Command line: --nsec nsec1...
Environment variable: NSEC=nsec1...
Config file: Automatically saved to .wallet.json
Auto-generate: Creates new key if none provided
When running as an MCP server, the following tools are available:
get_balance: Get the total wallet balance
get_mint_balances: Get balance breakdown per mint
deposit: Create a deposit invoice for specified amount and mint
pay: Pay a Lightning invoice
zap: Send a zap to a user
add_mint: Add a mint to the wallet
To use this wallet with Claude Code, add it to your project's MCP configuration:
{
"mcpServers": {
"mcp-money": {
"command": "npx",
"args": ["mcp-money"]
}
}
}Or install globally and reference the binary directly:
npm install -g mcp-money{
"mcpServers": {
"mcp-money": {
"command": "mcp-money"
}
}
}To use this wallet with Goose, add it to your ~/.config/goose/config.yaml:
If you have an nsec you want to use, you can set it by passing it as --nsec nsec1....
extensions:
money:
args:
- -y
- mcp-money
bundled: null
cmd: npx
description: Money for agents
enabled: true
env_keys: []
envs: {}
name: money
timeout: 300
type: stdioAfter adding the configuration, restart your AI assistant to begin using the wallet tools.
The wallet automatically creates a .wallet.json file to store:
Private key (nsec)
Public key (npub)
Configured relays
Configured mints
Cached mint information
Built on top of:
NDK: Nostr Development Kit for Nostr protocol interactions
NDK Wallet: Cashu wallet implementation
Nostr Tools: Low-level Nostr utilities
Bun: Fast JavaScript runtime and package manager
Private keys are stored locally in .wallet.json
Mint information is cached for performance
All Nostr communications use standard NIP protocols
Lightning payments require explicit confirmation
MIT
Fork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request
For issues and questions, please open an issue on the GitHub repository.
Add a mint to the wallet
| Name | Required | Description | Default |
|---|---|---|---|
| mintUrl | Yes | Mint URL to add |
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. 'Add a mint to the wallet' implies a mutation operation, but it lacks details on permissions, side effects, error conditions, or what happens if the mint already exists. This is inadequate for a tool that likely modifies state.
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's appropriately sized for a simple tool and front-loads the key action, 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 lack of annotations and output schema, the description is insufficient. It doesn't explain what 'adding a mint' entails behaviorally, what the expected outcome is, or how it relates to sibling tools. For a mutation tool with no structured safety hints, 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 input schema has 100% description coverage, with 'mintUrl' clearly documented. The description doesn't add any parameter details beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.
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 ('Add') and resource ('a mint to the wallet'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'deposit' or 'pay', which might also involve wallet modifications, so it doesn't reach the highest clarity level.
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, context (e.g., when a mint needs adding), or exclusions, leaving the agent with minimal usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a deposit invoice (bolt11) for the specified amount and mint. Returns the invoice immediately for payment. If no mint is specified, all mints will be tried concurrently and the first successful response will be used.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount in satoshis | |
| mintUrl | No | Mint URL to deposit to (optional - all mints tried concurrently if not provided) |
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 describes key behaviors: the tool returns an invoice immediately, and if no mint is specified, it tries all mints concurrently with the first successful response used. However, it lacks details on error handling, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by essential behavioral details in two concise sentences. Every sentence earns its place by adding critical information without redundancy or fluff.
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 financial transaction tool with no annotations and no output schema, the description is moderately complete. It covers the purpose and key behavior but lacks details on return values, error cases, or security implications, which are important for such a 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?
The schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema by reinforcing that 'mintUrl' is optional and explaining the concurrent mint behavior, but doesn't provide additional syntax or format 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 tool's purpose with specific verbs ('Create a deposit invoice') and resources ('bolt11'), specifying it's for a particular amount and mint. It distinguishes from sibling tools like 'pay' or 'zap' by focusing on invoice creation rather than payment execution.
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 clear context on when to use this tool (to generate a payment invoice) and includes an implicit alternative by noting that if no mint is specified, all mints are tried concurrently. However, it doesn't explicitly state when NOT to use it or compare it to alternatives like 'pay' for direct payments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the total wallet balance
| 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 for behavioral disclosure. While 'Get' 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 is returned in. The description is too minimal for a tool with zero 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 perfectly concise - a single clear sentence that communicates the essential purpose without any wasted words. It's front-loaded with the core functionality and doesn't contain unnecessary elaboration.
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 tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'total wallet balance' means (aggregated across all assets? specific currency?), what format the response will be in, or any behavioral characteristics. The agent would be left guessing about important operational 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?
The tool has zero parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't waste space discussing nonexistent parameters, though it could optionally mention that no parameters are required.
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 ('total wallet balance'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_mint_balances' which suggests there might be multiple balance-related tools without clear 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 about when to use this tool versus alternatives like 'get_mint_balances' or other sibling tools. There's no mention of prerequisites, context, or comparison with related tools, leaving the agent with insufficient usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get balance breakdown per mint
| 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 what the tool does but doesn't describe behavioral traits such as whether it's read-only, requires authentication, has rate limits, or what the output format looks like. This is inadequate for a tool with zero 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 with no 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 (a read operation with no parameters) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'balance breakdown' entails, the return format, or any behavioral context, leaving gaps for the agent to understand the tool fully.
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 the schema description coverage is 100%, so no parameter information is needed. The description doesn't add parameter semantics, but this is acceptable given the lack of parameters, aligning with the baseline for 0 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 verb 'Get' and the resource 'balance breakdown per mint', making the purpose understandable. However, it doesn't differentiate from the sibling tool 'get_balance', which could cause confusion about when to use each tool.
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 'get_balance' or other siblings. The description lacks context about prerequisites, timing, or exclusions, 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.
Pay a Lightning invoice
| Name | Required | Description | Default |
|---|---|---|---|
| bolt11 | Yes | Lightning invoice to pay |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a payment operation (implying a write/mutation), but doesn't mention permission requirements, whether it's idempotent, what happens on failure, or any rate limits. For a financial transaction tool, this is a significant gap in 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, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a single-parameter tool and gets straight to the point.
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 payment tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after payment (success/failure states, return values), doesn't mention security considerations, and provides minimal behavioral context despite the tool's significant implications.
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 'bolt11' parameter clearly documented as 'Lightning invoice to pay'. The description adds no additional parameter information beyond what's already in the schema, so it meets the baseline for high schema coverage without adding extra value.
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 invoice'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'deposit' or 'zap', but the specificity of 'Lightning invoice' provides inherent distinction for those familiar with the domain.
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 'deposit' or 'zap', nor does it mention any prerequisites or conditions for use. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a zap to a user
| Name | Required | Description | Default |
|---|---|---|---|
| recipient | Yes | User npub or NIP-05 identifier to zap | |
| amount | Yes | Amount in satoshis | |
| comment | No | Optional comment |
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 sending a zap but doesn't specify whether this is a payment operation, what permissions or authentication are required, if it's destructive (likely yes, as it sends funds), rate limits, or what happens on success/failure. This leaves critical 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, clear sentence with zero wasted words. It's appropriately sized and front-loaded, efficiently stating the core action without unnecessary elaboration.
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 tool with no annotations and no output schema, the description is incomplete. It doesn't explain what a zap entails (e.g., Lightning network transaction), return values, error conditions, or dependencies on other tools like 'get_balance' or 'deposit', leaving significant gaps for 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?
Schema description coverage is 100%, so the schema already documents all parameters (recipient, amount, comment). The description adds no additional meaning beyond what the schema provides, such as explaining what a 'npub' or 'NIP-05 identifier' is or providing context for the amount. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('send a zap') and target ('to a user'), which provides a basic purpose. However, it doesn't explain what a 'zap' is in this context (likely a Bitcoin Lightning payment given the satoshi amount parameter), nor does it differentiate from sibling tools like 'pay' or 'deposit', leaving the purpose somewhat 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 like 'pay' or 'deposit'. The description lacks context about prerequisites (e.g., needing a balance or mint setup), exclusions, or typical use cases, offering minimal usage direction.
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.
add_mintdepositget_balanceget_mint_balancespayzapScored across 6 tools
Most tools have distinct purposes, with 'deposit' for creating invoices, 'pay' for paying invoices, and 'zap' for sending zaps. However, 'get_balance' and 'get_mint_balances' could be slightly confusing as both relate to balance retrieval, though their descriptions clarify one is total and the other per-mint.
All tool names follow a consistent verb_noun pattern (e.g., add_mint, deposit, get_balance, get_mint_balances, pay, zap), with clear and readable conventions throughout the set.
With 6 tools, the server is well-scoped for a wallet and Lightning payment system, covering key operations like mint management, deposits, payments, and balance queries without being overly sparse or bloated.
The tool set covers core wallet and Lightning operations, including mint management, deposits, payments, and balance checks. A minor gap exists in lacking explicit tools for invoice status checks or transaction history, but agents can likely work around this for basic workflows.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for AI agents to discover campaigns by humans and donate USDC directly on Base.
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server for Gainium — manage trading bots, deals, and balances via AI assistants
