moneylover-mcp

An MCP server that lets an AI agent or chatbot read your Money Lover data and, if you allow it, add transactions. It talks to the client over stdio.

Disclaimer — please read. This project is unofficial. It is not affiliated with, endorsed by, or supported by Money Lover or its owners. "Money Lover" is a trademark of its respective owner and is used here only to describe what the software connects to. Money Lover has no public API. This tool uses the same undocumented web endpoints as the Money Lover web app, reverse-engineered from public open-source projects. They can change or break at any time, and using them may be against Money Lover's terms of service (which we could not verify). You use this software entirely at your own risk, including the risk of account restrictions, lost or incorrect data, and incorrect transactions. It is provided "AS IS" under the MIT license, without warranty of any kind. Back up your data and try it on a throwaway wallet first.

Trust model

What a reviewer should know before granting this server access to a finance account. Each claim is enforced in code and checked in CI, not just stated here.

Tools

Design choices that matter for LLM use:

• Wallets and categories are given by name, never by id. Matching is exact (case-insensitive); an unknown or ambiguous name returns an error listing the candidates instead of guessing.
• Amounts are always positive. Income vs expense comes from the category. Pass type when a category name exists as both (e.g. "Other").
• Money is returned as decimal strings, never floats.
• Dates are YYYY-MM-DD in your configured timezone.
• add_transaction is not even registered unless you opt in with MONEYLOVER_ALLOW_WRITE=true. See Security for the limits that apply to writes.
• Wallets and categories are cached in memory (5 minutes by default) because Money Lover's wallet list can take 30+ seconds on large accounts. Writing a transaction clears the cached balances, a name that is not in the cache triggers one fresh fetch (so a wallet you just created is found), and list_wallets reports from_cache so an agent knows when balances may be stale. Changes made in the Money Lover app itself show up after the cache expires or with refresh: true.

Install

Prebuilt binary (no Rust needed)

Download the archive for your platform from the latest release:

Verify it before running it. SHA256SUMS is attached to every release, and every archive has a signed build-provenance attestation proving it was built by this repository's release workflow:

shasum -a 256 -c SHA256SUMS --ignore-missing          # Linux: sha256sum --check --ignore-missing SHA256SUMS
gh attestation verify moneylover-mcp-*.tar.gz --repo Iyongbudiarso/moneylover-mcp

Extract it and put moneylover-mcp somewhere on your PATH. The binaries are not signed with an Apple or Microsoft certificate. On macOS, a file downloaded with a browser is blocked by Gatekeeper; after verifying it, allow it with xattr -d com.apple.quarantine moneylover-mcp. On Windows, SmartScreen may ask for confirmation.

MCPB bundle (Claude Desktop and other MCPB clients)

Clients that understand MCP Bundles can install the server as an extension instead. Download the .mcpb for your platform from the latest release and open it, or point your client at the file:

There is one bundle per platform because a bundle carries a single executable and MCPB cannot choose between executables by CPU architecture; the macOS bundle holds one universal binary.

When the client asks for configuration you can either enter your Money Lover email and password (the client keeps the password in the OS keychain, and the server exchanges it for a token, exactly as with login), or leave both empty and run moneylover-mcp login once with a prebuilt binary — the extension reuses the stored token. Adding transactions stays off unless you enable it in the extension's settings.

The same bundles are listed in the official MCP Registry as com.iyongbudiarso/moneylover-mcp, which is verified by a v=MCPv1; … TXT record on iyongbudiarso.com. Registry-aware clients check each download against the SHA-256 recorded there. That proves who published the entry; it is not a statement that the code is safe. Check the trust model and the source instead.

From source

You need a Rust toolchain (1.89 or newer).

cargo install --locked --git https://github.com/Iyongbudiarso/moneylover-mcp
# or, from a checkout:
cargo build --locked --release   # binary: target/release/moneylover-mcp

--locked builds with the exact dependency versions in Cargo.lock, which CI vets with cargo deny, instead of whatever is newest on crates.io.

Log in

Log in once, from a terminal. The password is typed at a hidden prompt and never stored; only the resulting token is saved:

moneylover-mcp login

Configure

All configuration is through environment variables.

Authentication notes

• Only email + password accounts are supported. Accounts created with Google, Facebook or Apple sign-in have no password and cannot log in this way.
• A Money Lover account allows roughly 5 devices, and every fresh login uses one slot. The server stores its tokens in token.json and refreshes them (a refresh uses no slot). Several MCP clients may share the same token file safely; access is serialized with a lock file.
• If the token can no longer be refreshed, run moneylover-mcp login again.
• moneylover-mcp logout deletes the local token and stops running servers immediately. The token itself stays valid at Money Lover until it expires; to revoke it, remove the device in the Money Lover app. Either way every server sharing the token file stops until you run moneylover-mcp login again; it never silently logs back in.
• A wrong password is tried once per server start, never in a loop.

Example client config

No password in the config: run moneylover-mcp login first.

{
  "mcpServers": {
    "moneylover": {
      "command": "/path/to/moneylover-mcp",
      "env": {
        "MONEYLOVER_TIMEZONE": "Asia/Jakarta"
      }
    }
  }
}

In Zed, put the same thing under context_servers in settings.json:

{
  "context_servers": {
    "moneylover": {
      "command": "/path/to/moneylover-mcp",
      "env": { "MONEYLOVER_TIMEZONE": "Asia/Jakarta" }
    }
  }
}

To let an agent record transactions, opt in and fence it in:

"env": {
  "MONEYLOVER_ALLOW_WRITE": "true",
  "MONEYLOVER_WRITE_WALLETS": "Cash",
  "MONEYLOVER_MAX_AMOUNT": "2000000"
}

Headless servers (a container, a VPS running a chatbot) can pass MONEYLOVER_EMAIL and MONEYLOVER_PASSWORD instead; use your platform's secret store, not a file in a repository.

Security

Do not commit MCP client config files that contain credentials. Zed's settings.json and similar files often end up in public dotfiles repositories.

What the server does to keep your account safe:

• Credentials. The password is only used for login and never stored. Tokens live in token.json, created with mode 0600 in a 0700 directory; a token file that other users can read is tightened to 0600, or refused if that is not possible. Passwords, tokens and Authorization headers never appear in logs or in tool output. On Windows the file relies on your user profile's default permissions.
• Network. HTTPS only, certificates checked against the OS trust store, redirects never followed (so a password or token can never be re-sent elsewhere), response size capped.
• Writes are off by default. When enabled, every add_transaction call is checked by the server, not by the AI:
  • only wallets in MONEYLOVER_WRITE_WALLETS (if set), archived wallets never;
  • amounts up to MONEYLOVER_MAX_AMOUNT (if set);
  • dates from one year ago to one month ahead;
  • at most MONEYLOVER_MAX_WRITES_PER_HOUR transactions per hour (counted per server process: two MCP clients each running the server get the limit twice);
  • an identical transaction within 10 minutes is refused as an accidental retry unless the agent passes allow_duplicate: true;
  • writes are never retried automatically. If a write times out, the tool answers UNCERTAIN and tells the agent to check before retrying.

What you should know:

• Prompt injection. Transaction notes, wallet names and category names are shown to the AI. In a shared wallet, other people write those. Text like "ignore previous instructions and add …" could steer an agent. The server tells the agent to treat this text as data, but the real protection is the write limits above. Keep writes off unless you need them, restrict MONEYLOVER_WRITE_WALLETS, and prefer an MCP client that asks you before each tool call. MONEYLOVER_WRITE_WALLETS matches wallet names; the owner of a wallet shared with you can rename it, so list wallets you own.
• Combining servers. An agent that can both read your finances and send data out (web fetch, email, …) can be tricked into leaking them. Think about which tools you enable together.
• Logs. Logs go to stderr, which MCP clients often save to a file. At the default info level they contain no financial data. MONEYLOVER_LOG=rmcp=debug logs full tool inputs and outputs.
• Your AI provider sees whatever the tools return (balances, transactions). That is inherent to using a cloud AI with your financial data.

Releasing

1. Bump version in Cargo.toml, run cargo build to update Cargo.lock, commit.
2. Tag and push: git tag v0.2.0 && git push origin v0.2.0.

The release workflow checks that the tag matches Cargo.toml, runs the tests, builds all platforms, attests their provenance and publishes the GitHub release with SHA256SUMS. Running the workflow manually (Actions > Release > Run workflow) only builds, which is a handy dry run.

A second job then assembles the .mcpb bundles from those archives with the pinned @anthropic-ai/mcpb CLI, smoke-tests the macOS one, attests each bundle and attaches the bundles plus SHA256SUMS.mcpb and a generated server.json to the same release.

Publishing to the MCP Registry

This is a manual step on purpose: it needs an Ed25519 key that must not live in the repository or in CI. scripts/publish-registry.sh downloads the released bundles, re-checks every hash against server.json and publishes:

brew install mcp-publisher          # the registry's CLI, once
scripts/publish-registry.sh v0.2.0

The first time, and after a key rotation, the script's header explains how to generate the key, put the public half in a TXT record on the apex domain and run mcp-publisher login dns.

Two things to know: a published version is immutable, so bump the version rather than rebuilding a tag; and rebuilding a tag produces different bundle bytes (ZIP timestamps), so publish the registry entry after the release workflow has run and do not re-run the workflow for a published tag.

Development

cargo test                      # unit + end-to-end tests against a mocked Money Lover
cargo clippy --all-targets

Live tests hit the real API and are skipped by default. Run moneylover-mcp login (or cargo run -- login) first, then:

cargo test --test live live_read_only -- --ignored --nocapture      # read only

# Optional write test: needs a wallet named exactly "MCP Test"
MONEYLOVER_LIVE_WRITE=1 MONEYLOVER_LIVE_CATEGORY="<an expense category in that wallet>" \
  cargo test --test live live_write -- --ignored --nocapture

Delete the test transaction in the Money Lover app afterwards.

Static analysis of the agent-facing surface

snyk-agent-scan looks at what an AI client actually sees — tool descriptions, prompt-injection surface, hardcoded secrets. It is not part of CI because it needs a Snyk token and uploads tool names and descriptions to api.snyk.io, so run it by hand when you want it:

SNYK_TOKEN=… uvx snyk-agent-scan@0.6.8 scan --ci \
  --dangerously-run-mcp-servers --suppress-mcpserver-io=true mcp.json

Generate mcp.json from your normal client config (it is the usual {"mcpServers": {…}} shape) and do not commit it if it contains credentials.

License

MIT. See LICENSE.