moneylover-mcp

List wallets

moneylover_list_wallets

Read-only

List every wallet in the Money Lover account with its currency, balance and flags. Use it to resolve a wallet name into the exact spelling other tools expect, or to look up a balance before adding a transaction.

Instructions

List every wallet in the Money Lover account with its currency, balance and flags. Use it to resolve a wallet name the user mentioned into the exact spelling the other tools expect; they match it case-insensitively. For totals use moneylover_summarize_spending; for categories use moneylover_list_categories. Behavior: refresh is the only parameter. A live fetch costs tens of seconds on large accounts and leaves the fresh list in the cache for later calls, so request it only when the user needs a live figure; otherwise the list comes from a cache a few minutes old, which from_cache reports. Archived wallets are included and flagged; they cannot receive new transactions.

Input Schema

Name	Required	Description	Default
`refresh`	No	Set to true to bypass the short-lived cache and fetch live balances. Slow on large accounts, so leave it unset (default false) unless the user explicitly needs a live figure.

Output Schema

Name	Required	Description	Default
`wallets`	Yes
`from_cache`	Yes	True when served from the short-lived cache; balances may then be a few minutes old.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.5.0Oct 27, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint, so the description carries the rest and does it well: caching semantics (cache a few minutes old, from_cache reports which), the cost of a live fetch (tens of seconds on large accounts), the side effect of a refresh populating the cache for later calls, and the fact that archived wallets are returned and flagged but cannot receive new transactions.

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?

Front-loaded with what the tool returns and its main use, then alternatives, then behavior; every sentence carries information. It is dense and semicolon-heavy in the behavior clause, and 'refresh is the only parameter' mildly restates the schema, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A single optional parameter, readOnlyHint annotation and an existing output schema mean the description needs only to cover purpose, caching and archive semantics — all of which are present. Nothing an agent needs in order to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so refresh is already documented at baseline 3. The description adds meaning beyond the schema by explaining that a live fetch leaves the fresh list in the cache for subsequent calls and that the default result may be a few minutes stale, which an agent needs in order to decide whether to set it.

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?

States a specific verb and resource ('List every wallet in the Money Lover account') and immediately names what the record contains — currency, balance, flags. It is unambiguously distinguishable from the transaction, category and spending siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit primary use case (resolve a wallet name the user mentioned into the exact spelling other tools expect) plus explicit alternatives with their own conditions: moneylover_summarize_spending for totals and moneylover_list_categories for categories. It also states when to set refresh and when to leave it unset.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server