A
licenseNot graded
qualityD
maintenanceEnables AI agents to manage personal expenses through natural language conversations. Supports adding, searching, and analyzing transactions with automatic categorization and financial insights.
3
MIT
Money Lover MCP Server
by ferdhika31
This MCP server enables AI assistants to interact with Money Lover financial data through authentication and comprehensive management tools.
Authentication & User Management
Login using email and password credentials to obtain JWT tokens
Retrieve user profile information associated with authenticated sessions
Automatic token caching and refresh in
~/.moneylover-mcp/directoryEnvironment-based authentication (EMAIL/PASSWORD) with manual token override support
Wallet Operations
List all wallets accessible to the authenticated user
Access expense/income categories specific to a designated wallet ID
Transaction Management
Query transactions within a specified date range for any wallet
Create new transactions by specifying wallet ID, category ID, amount, date, and optional notes or related parties
Integration
Works with MCP-compliant clients like Claude Desktop and Cursor through stdio interface
Configurable via environment variables for seamless setup
Provides a Node.js implementation of an MCP server that wraps the Money Lover REST API, enabling authentication, wallet management, transaction querying, and creation of new transactions
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., "@Money Lover MCP Servershow my spending for this month"
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.
Money Lover MCP Server
Node.js implementation of a Model Context Protocol (MCP) server that wraps the unofficial Money Lover REST API. The server exposes authentication and wallet management capabilities as MCP tools, enabling AI assistants or compatible MCP clients to login, inspect wallets, query transactions, and create new transactions.
Features
Login tool returns Money Lover JWT tokens via the public OAuth flow.
Tools for retrieving user info, wallets, categories, and transactions.
Tool for adding new transactions, mirroring the behaviour of the Go reference client.
Stdio-based server entrypoint that can be consumed by MCP-aware clients.
Node-friendly REST wrapper for direct programmatic usage.
Related MCP server: Money Manager MCP Server
Prerequisites
Node.js 22 or newer.
Money Lover account credentials for authentic API access.
Installation
npm installUsage
Launch the MCP server over stdio (suitable for tools such as Claude Code, Cursor, or other MCP hosts):
npm startMCP Client Configuration
Configure an MCP-compliant client (for example, Claude desktop or Cursor) to invoke the published package via npx and supply credentials through environment variables:
{
"mcpServers": {
"mcp-moneylover": {
"command": "npx",
"args": ["@ferdhika31/moneylover-mcp@latest"],
"env": {
"EMAIL": "alamat-email-anda@example.com",
"PASSWORD": "kata-sandi-anda"
}
}
}
}The server automatically logs in with the provided credentials and refreshes the session token when required. Supplying a token argument to tools overrides the environment-based authentication.
Tokens resolved through the login tool or environment credentials are cached per-email under ~/.moneylover-mcp/. Cached tokens are reused on subsequent runs and refreshed automatically when the API reports they have expired.
The server registers the following tools:
Tool | Description | Required Arguments |
| Retrieves a JWT token using email & password. |
|
| Returns profile information tied to the token. |
|
| Lists wallets available to the authenticated user. |
|
| Lists categories for a wallet. |
|
| Retrieves transactions in a date range. |
|
| Creates a new transaction. |
|
Tokens are not persisted; provide them explicitly when invoking tools other than login.
Library Usage
The underlying REST wrapper is available for reuse:
import { MoneyloverClient } from '@ferdhika31/moneylover-mcp';
const token = await MoneyloverClient.getToken(email, password);
const client = new MoneyloverClient(token);
const wallets = await client.getWallets();Testing
Run the automated test suite:
npm testTests rely on mocked fetch responses and do not hit the live Money Lover service.
Security Notes
Never commit real credentials or tokens.
The project intentionally avoids persisting tokens; MCP clients should store secrets securely on their side.
Cached tokens are stored locally with file permissions restricted to the current user. Delete the
~/.moneylover-mcp/directory if you need to revoke stored sessions.
Available Tools
6 toolsadd_transactionAdd TransactionC
Create a new transaction in a wallet.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | JWT token returned by the login tool or derived from EMAIL/PASSWORD environment variables | |
| walletId | Yes | Wallet identifier | |
| categoryId | Yes | Category identifier | |
| amount | Yes | Transaction amount as string | |
| note | No | Optional transaction note | |
| date | Yes | Display date in YYYY-MM-DD format | |
| with | No | Optional array of related parties |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It only states 'create' implying mutation, but lacks details on side effects, authentication requirements, error states, or what happens on success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. It is concise but could include more context without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is insufficient. It does not explain return value, constraints, or what happens after creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new transaction in a wallet,' which clearly identifies the action and resource. It distinguishes from sibling tools like get_categories and get_transactions, which are read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., other write tools). No prerequisites or conditions mentioned, such as requiring authentication via the token parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_categoriesGet CategoriesB
Retrieve categories for a specific wallet.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | JWT token returned by the login tool or derived from EMAIL/PASSWORD environment variables | |
| walletId | Yes | Wallet identifier |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| categories | Yes |
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, if authentication is required (though the token parameter implies it), or any potential side effects. Minimal 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no unnecessary words. It is front-loaded with the core purpose and uses no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple retrieval tool, especially with an existing output schema. However, it lacks any additional context about the nature of categories (e.g., hierarchy, filtering) or usage hints beyond the basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions, so schema_description_coverage is 100%. The description adds no additional parameter meaning beyond what is already in 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve') and resource ('categories') with a specific scope ('for a specific wallet'). It distinguishes this tool from siblings like 'add_transaction' or 'get_wallets' by focusing on categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It only states what the tool does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transactionsGet TransactionsB
Fetch transactions for a wallet between two dates.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | JWT token returned by the login tool or derived from EMAIL/PASSWORD environment variables | |
| walletId | Yes | Wallet identifier | |
| startDate | Yes | Start date in YYYY-MM-DD format | |
| endDate | Yes | End date in YYYY-MM-DD format |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only says 'fetch' but does not disclose any behavioral traits such as read-only nature, authentication requirements, or potential 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema provided, and description omits return format, pagination, error handling, or any additional context. Inadequate for a fetch tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents each parameter. Description adds no extra meaning beyond the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetch transactions for a wallet between two dates', specifying verb, resource, and scope. Distinguishes from siblings like add_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., add_transaction). No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_user_infoGet User InfoA
Retrieve the Money Lover user profile associated with the provided token.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | JWT token returned by the login tool or derived from EMAIL/PASSWORD environment variables |
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It states a retrieval operation but omits details like no side effects, auth requirements beyond token, or data returned. Adequate for a simple read, but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words. Front-loaded with purpose. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is minimal. It does not explain return values or the structure of the user profile. Adequate for a simple tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (100%) with clear param description. Tool description adds no new meaning beyond schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves the user profile, using a specific verb-resource combination (Retrieve user profile). It is distinct from sibling tools like login, add_transaction, etc., which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies the token is required, indicating it should be used after obtaining a token. However, it does not explicitly state when to use or when to avoid, nor provides alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_walletsGet WalletsB
List all wallets accessible to the authenticated user.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | JWT token returned by the login tool or derived from EMAIL/PASSWORD environment variables |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| wallets | Yes |
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'List all wallets...', which implies a read operation but does not explicitly confirm safety, side effects, or authentication requirements beyond the schema parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, direct sentence with no unnecessary words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and full schema parameter coverage, the minimal description is adequate for a simple list tool, but lacks mention of possible errors or pagination behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema's parameter description already covers the token. The tool description adds no additional meaning about the parameter, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('wallets'), and clearly limits scope to 'accessible to the authenticated user', effectively distinguishing it from sibling tools like add_transaction or get_user_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any mention of prerequisites or limitations. The agent receives 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.
loginLogin to Money LoverA
Authenticate using Money Lover credentials to retrieve a JWT token.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Money Lover account email | ||
| password | Yes | Money Lover account password |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| token | Yes |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes retrieving a token but does not disclose side effects or that the token should be stored for subsequent requests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no unnecessary words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists but description does not mention that the token must be used for authorization in other endpoints. Missing context for the authentication flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (authenticate), resource (Money Lover credentials), and output (JWT token). Distinguishes from sibling tools that handle transactions, categories, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied that this is the authentication step before using other tools, but no explicit guidance on when to use, prerequisites, or alternatives. Could be more helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A3.5/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: authentication, user info, wallets, categories, and transactions (add and fetch). No two tools overlap in functionality.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., add_transaction, get_categories), but 'login' deviates by being a single verb. This minor inconsistency does not cause confusion.
Tool Count5/5
With 6 tools, the server is well-scoped for a personal finance API covering essential operations like authentication, wallet and category retrieval, and transaction management.
Completeness3/5
The set covers basic CRUD for transactions (only create and read) and read-only for categories and wallets. Missing update/delete for transactions and full wallet/category management, which are notable gaps for a finance tool.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Log, query, and edit expenses, budgets, and accounts in Manilo (formerly Ledgy) from any MCP-compatible AI assistant.
Log, query, and edit expenses, budgets, and accounts in Manilo from any MCP-compatible AI assistant.
Personal finance for AI agents: accounts, budgets, goals, 9-strategy debt payoff, reports. OAuth 2.1
Track expenses, budgets, balances, transfers, and multi-currency reports with OAuth-secured tools.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables AI assistants to manage personal finances through the Realbyte Money Manager mobile app, providing transaction management, asset tracking, credit card monitoring, and financial analytics with 18 comprehensive tools.183012MIT
- AlicenseAqualityDmaintenanceEnables AI assistants to query and manage personal finance data through the unofficial Money Lover REST API. It provides 27 tools covering authentication, wallets, categories, transactions, events, debts, and static configuration with both read and write capabilities.3332ISC
- AlicenseBqualityDmaintenanceEnables AI agents to interact with your Lunch Money personal finance data, providing tools for managing transactions, categories, budgets, assets, and accounts.1524ISC
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ferdhika31/moneylover-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server