The ZenMoney MCP server is primarily a read-only tool for syncing and analyzing ZenMoney financial data in-memory, with optional write capabilities if explicitly enabled.
Sync Management
sync_run: Trigger a full or incremental sync of the in-memory ZenMoney snapshot
sync_status: Check the current cache and synchronization status
Accounts
accounts_list: List all accounts, with optional inclusion of archived ones
Transactions
transactions_list: List transactions with filters (date range, account, payee, tag, merchant, deleted status, limit)
transactions_get: Retrieve a single transaction by ID
transactions_suggest: Get AI-based suggestions for transaction payee, merchant, or tags
Tags / Categories
tags_list: List all tags/categories, optionally including archived ones
Merchants
merchants_list: List merchants with optional text search and result limit
Budgets
budgets_list: List budgets filtered by month, tag, or user
budgets_get_status: Calculate category budget status (configured amount, actual spending, remaining, overspend) with optional child category inclusion
Optional Write Tools (require explicit opt-in via flag or env var)
Create, update, and delete: accounts, transactions, tags, merchants, reminders, and reminder markers
Update/delete operations require expectedChanged for conflict detection
⚠️ Budget writes are not supported
The server does not persist financial data or API responses to disk, making it safe for read-heavy agentic workflows like financial analysis, reporting, and anomaly detection.
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., "@ZenMoney MCP show my spending for the last 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.
Read-only MCP server for ZenMoney. It syncs ZenMoney data into process memory and exposes it through MCP tools and resources. It does not persist financial data or API responses to disk.
The read-only mode is a good fit for agentic workflows with tools such as Hermes and OpenClaw. Agents can analyze transactions in the way the user asks, compare spending patterns, prepare recurring personal-finance reports, and surface anomalies without being able to create, update, or delete ZenMoney data.
Related MCP server: mcp-beancount
This is an unofficial project and is not affiliated with, endorsed by, or sponsored by ZenMoney. Users are responsible for complying with ZenMoney terms and for protecting their own access tokens.
Use the published CLI through npx and pass runtime configuration through your MCP client:
{
"mcpServers": {
"zenmoney": {
"command": "npx",
"args": ["-y", "@nonnname/zenmoney-mcp"],
"env": {
"ZENMONEY_ACCESS_TOKEN": "paste-token-here",
"ZENMONEY_SYNC_ON_START": "true",
"ZENMONEY_API_BASE_URL": "https://api.zenmoney.ru/v8",
"ZENMONEY_DEFAULT_RESULT_LIMIT": "100",
"ZENMONEY_MAX_RESULT_LIMIT": "500",
"ZENMONEY_REQUEST_TIMEOUT_MS": "30000",
"ZENMONEY_ENABLE_WRITE_TOOLS": "false"
}
}
}
}The same example is available in mcp-config.example.json.
ZENMONEY_ACCESS_TOKEN=
ZENMONEY_SYNC_ON_START=true
ZENMONEY_API_BASE_URL=https://api.zenmoney.ru/v8
ZENMONEY_DEFAULT_RESULT_LIMIT=100
ZENMONEY_MAX_RESULT_LIMIT=500
ZENMONEY_REQUEST_TIMEOUT_MS=30000
ZENMONEY_ENABLE_WRITE_TOOLS=falseZENMONEY_DEFAULT_RESULT_LIMIT and ZENMONEY_MAX_RESULT_LIMIT limit MCP responses from the in-memory snapshot. They do not limit ZenMoney API synchronization.
npm install
cp .env.example .env
npm run devFor a production-like local run from source:
npm run build
npm startsync_run
sync_status
accounts_list
transactions_list
transactions_get
transactions_suggest
tags_list
merchants_list
budgets_list
budgets_get_status
budgets_get_status calculates read-only category budget status for a month. It reports the configured outcome budget, actual spending, remaining amount, overspend state, and matched category ids. Child categories are included by default with includeChildren: true.
The server is read-only by default. Write tools are not registered unless you explicitly enable them at process startup.
Enable write tools with a launch argument:
{
"mcpServers": {
"zenmoney": {
"command": "npx",
"args": ["-y", "@nonnname/zenmoney-mcp", "--enable-write-tools"],
"env": {
"ZENMONEY_ACCESS_TOKEN": "paste-token-here"
}
}
}
}Or enable write tools with an environment variable:
{
"env": {
"ZENMONEY_ACCESS_TOKEN": "paste-token-here",
"ZENMONEY_ENABLE_WRITE_TOOLS": "true"
}
}Write tools can create, update, and delete ZenMoney user entities except budgets. Update and delete tools require expectedChanged, which is the changed value returned by the read tools. If the entity changes remotely before the write, the server returns a conflict and does not send the mutation.
Budget writes are not supported.
Write tools registered only after opt-in:
accounts_create
accounts_update
accounts_delete
transactions_create
transactions_create_expense
transactions_create_income
transactions_create_transfer
transactions_update
transactions_delete
tags_create
tags_update
tags_delete
merchants_create
merchants_update
merchants_delete
reminders_create
reminders_update
reminders_delete
reminder_markers_create
reminder_markers_update
reminder_markers_delete
zenmoney://status
zenmoney://accounts
zenmoney://transactions
zenmoney://transactions/{id}
zenmoney://tags
zenmoney://merchants
zenmoney://budgets
zenmoney://schema/account
zenmoney://schema/transaction
zenmoney://schema/tag
zenmoney://schema/merchant
zenmoney://schema/budget
Contributor setup, verification, and maintainer release instructions live in CONTRIBUTING.md.
List accounts from the in-memory ZenMoney snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| includeArchived | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It reveals the data source (in-memory snapshot) but does not state whether it is read-only, what happens if the snapshot is empty, or any side effects. The agent has limited insight into behavioral traits.
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. Every word contributes meaning. It is appropriately sized for a simple list operation.
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 has one boolean parameter, no output schema, and no annotations, the description provides the bare minimum. It states the action and data source but lacks details about return format, default parameter values, or how archived accounts are handled. It is 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 description coverage is 0%, yet the description adds no explanation for the 'includeArchived' parameter. The parameter name is self-explanatory, but the description does not confirm its meaning or default behavior, leaving the agent to infer.
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 'list' and resource 'accounts', and specifies the data source as 'in-memory ZenMoney snapshot', which differentiates it from a live API. However, it does not explicitly distinguish from sibling list tools like budgets_list or merchants_list, though the resource name is distinct.
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 conditions, prerequisites, or exclusions. The agent must rely solely on the resource name to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate read-only spending and remaining amount for a category budget.
| Name | Required | Description | Default |
|---|---|---|---|
| month | Yes | ||
| tagId | Yes | ||
| includeChildren | No | ||
| userId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the operation is 'read-only', which is a key behavioral trait. However, no other behavioral details (e.g., authentication, response format, error conditions) are provided, and there are no annotations to supplement.
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. However, it sacrifices necessary detail for brevity, making it slightly under-specified.
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 has 4 parameters, no output schema, and no annotations, the description is insufficient. It covers the basic purpose but lacks return value documentation, parameter descriptions, and error handling 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?
With 0% schema coverage, the description adds no value beyond the parameter names and types in the schema. It does not explain the meaning or expected format of month, tagId, includeChildren, or userId.
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?
Clearly states that the tool calculates read-only spending and remaining amount for a category budget. The verb 'calculate' and resource 'budget status' are specific and distinguish from sibling tools like budgets_list or transactions_get.
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 does not provide any guidance on when to use this tool versus alternatives such as budgets_list or transactions_list. No context on prerequisites or exclusions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List budgets from the in-memory ZenMoney snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| month | No | ||
| tagId | No | ||
| userId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions the in-memory snapshot, hinting at non-real-time data, but fails to disclose side effects, authentication requirements, or other behavioral traits.
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 efficiently conveys the verb and resource. However, it may be too sparse for full clarity.
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 three parameters and no output schema, the description is incomplete. It does not specify return format, filtering behavior, or expected data formats for parameters like month.
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 0%, but the description does not explain any parameters (month, tagId, userId). Without additional context, an AI agent cannot properly utilize these 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 action (List) and resource (budgets), and specifies the data source (in-memory ZenMoney snapshot). However, it does not explicitly distinguish from siblings like budgets_get_status, which also deals with budgets.
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 or any prerequisites. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List merchants from the in-memory ZenMoney snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions 'in-memory snapshot', hinting at non-live data, but does not disclose side effects, required permissions, or any other behavioral traits. Additional information about return behavior or performance implications would be needed.
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 the action and source. While concise, it omits essential parameter information, making it slightly under-specified. However, it is front-loaded and has no wasted words.
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 two optional parameters and no output schema, the description is incomplete. It does not describe the return format, sorting, pagination, or how parameters affect results. For a tool with no annotations, more context is necessary.
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 0%, and the description does not clarify the meaning of 'query' or 'limit' parameters. Without any explanation, the description adds no value beyond the schema, failing to compensate for the low coverage.
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 'List' and the resource 'merchants', and specifies the data source as 'the in-memory ZenMoney snapshot'. This distinguishes it from sibling tools like accounts_list or transactions_list, making the purpose unambiguous.
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. There is no mention of prerequisites, filtering capabilities, or when not to use it. The description lacks context for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Synchronize the in-memory ZenMoney snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| full | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits like side effects, safety, or required permissions. It only states the action without any additional 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 extremely concise (one sentence), but it is underspecified. Conciseness should not come at the cost of clarity and completeness. It fails to earn its place as a helpful definition.
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 (1 param, no output schema), the description should at least explain the parameter and basic behavior. It is incomplete, leaving critical gaps for correct use.
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 one boolean parameter 'full' with 0% description coverage, and the tool description does not mention it at all. The agent has no way to understand the parameter's purpose or effect.
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 verb 'synchronize' and the resource 'in-memory ZenMoney snapshot', which distinguishes it from read-only sibling tools. However, 'synchronize' is vague and does not explain what synchronization entails or what 'in-memory snapshot' means.
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 vs. alternatives like sync_status. The description implies usage for synchronization but offers no exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return memory cache initialization and synchronization status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states the return value without disclosing behavioral traits like idempotency, side effects, or safety. With no annotations, more detail is needed.
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 of 7 words, no filler. Front-loaded with purpose. Every word earns its place.
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?
Tool is simple with no parameters and no output schema. The description states it returns status but lacks detail on the format or possible values, which would help completeness without an output schema.
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?
No parameters exist, so baseline score of 4 applies. The description does not need to add parameter meaning beyond the schema, which has 100% coverage.
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 'Return' and the resource 'memory cache initialization and synchronization status', making the tool's purpose explicit. It distinguishes from sibling tools like sync_run which performs sync actions.
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 such as sync_run. The description does not mention prerequisites or context for checking status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tags/categories from the in-memory ZenMoney snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| includeArchived | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions 'in-memory ZenMoney snapshot', indicating it reads cached data not live data. This is useful behavioral context beyond a simple read operation. However, no annotations exist, and it doesn't specify behavior when snapshot is unavailable or if the tool is destructive (it's not).
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?
Description is a single concise sentence that starts with the verb and resource. It is efficient but misses parameter details. Could be slightly improved 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?
Given the tool has one undocumented parameter and no output schema or annotations, the description should include at least the parameter's meaning. It fails to provide complete context for correct invocation.
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?
Input schema has one parameter 'includeArchived' (boolean) with no description coverage. The description does not mention this parameter at all, leaving its purpose unclear. Agent must infer from name.
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 it lists tags/categories from the in-memory snapshot. Verb 'list' and resource 'tags/categories' are specific. However, it doesn't distinguish between tags and categories if they are separate entities, but siblings make it clear these are different from accounts, budgets, etc.
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 merchants_list or transactions_list. No exclusions or prerequisites mentioned. The description only states what it does, not when 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 one transaction by id from the in-memory ZenMoney snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'in-memory snapshot', hinting at data sourcing, but omits details on error handling (e.g., not found), permissions, or side effects. Acceptable for a simple get operation but could be more explicit.
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 that efficiently conveys the core functionality without any fluff. Every word contributes to understanding.
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 a simple interface, the description lacks information about return values (no output schema), error states, or pagination. For a tool that retrieves a single entity, more context on expected behavior (e.g., null or error for missing ID) 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 description coverage is 0%, and the description adds no additional meaning to the 'id' parameter beyond its name and type. The tool description fails to clarify what the ID represents or any constraints on its format.
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 retrieves one transaction by its ID, specifying the source as 'in-memory ZenMoney snapshot'. This distinguishes it from siblings like transactions_list, which retrieves multiple 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?
The description implies use when you have a specific transaction ID, but lacks explicit guidance on when to prefer this over alternatives like transactions_list or transactions_suggest. No when-not-to-use advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List transactions from the in-memory ZenMoney snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| dateFrom | No | ||
| dateTo | No | ||
| accountId | No | ||
| tagId | No | ||
| merchantId | No | ||
| payee | No | ||
| includeDeleted | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description only says 'list transactions' but lacks disclosure of behavioral traits such as read-only nature, side effects, authorization needs, or pagination. No annotations provided to compensate.
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 short (one sentence) but lacks essential detail. Conciseness is not simply brevity; it should pack useful information without waste. Here, it's under-specified.
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 8 parameters, no output schema, no annotations, and multiple sibling tools, the description is severely incomplete. It does not explain query parameters, return structure, or behavior.
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 0% and description adds no parameter information for any of the 8 parameters. Description fails to explain filtering capabilities like date range, account, or tags.
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 'List transactions' with a specific resource and source ('in-memory ZenMoney snapshot'). However, it does not differentiate from sibling tools like transactions_get or transactions_suggest.
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. Does not mention when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask ZenMoney to suggest transaction payee, merchant, or tags.
| Name | Required | Description | Default |
|---|---|---|---|
| payee | No | ||
| merchant | No | ||
| amount | No | ||
| accountId | No | ||
| date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden but only says 'suggest' without explaining behavior, return format, or side effects. Unclear if it's a read operation or mutates anything.
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 conveying core function; no redundant words. However, could be slightly more informative 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?
Tool has 5 parameters, no annotations, no output schema. Description fails to explain relationship between input fields and suggestions, or expected output format, leaving agent under-informed.
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 0%, and description only mentions payee, merchant, or tags, ignoring amount, accountId, and date. Provides minimal meaning beyond schema field names.
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 suggests transaction payee, merchant, or tags, distinguishing it from sibling list/get tools. Verb 'suggest' and resource 'transaction attributes' are specific.
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 merchants_list or tags_list. No exclusions or prerequisites mentioned.
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.
v0.2.0accounts_listbudgets_get_statusbudgets_listmerchants_listsync_runsync_statustags_listtransactions_gettransactions_listtransactions_suggestzenmoney_cache_statuszenmoney_get_transactionzenmoney_list_accountszenmoney_list_budgetszenmoney_list_merchantszenmoney_list_tagszenmoney_list_transactionszenmoney_suggest_transactionzenmoney_syncv0.1.0zenmoney_cache_statuszenmoney_get_transactionzenmoney_list_accountszenmoney_list_budgetszenmoney_list_merchantszenmoney_list_tagszenmoney_list_transactionszenmoney_suggest_transactionzenmoney_syncScored across 10 tools
Each tool targets a distinct entity or operation: listing for accounts, budgets, merchants, tags, and transactions; plus specific operations like get, suggest, sync, and status. No overlapping purposes.
All tools follow a consistent 'entity_verb' pattern (e.g., accounts_list, sync_run). While the order differs from the typical 'verb_noun', the pattern is uniform across the entire set.
With 10 tools, the server covers core operations for a read-only snapshot viewer: listing all entities, specific retrieval, suggestion, and synchronization management. This is well-scoped.
The tool set provides list operations for all major entities and a get for transactions, but lacks individual get endpoints for accounts, budgets, merchants, and tags. This leaves gaps for detailed inspection.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Personal finance for AI agents — onboard, import statements, categorize & budget over MCP.
Query your real net worth, spending, transactions, budgets and portfolio from any MCP client.
MCP server exposing the Backtest360 engine API as tools for AI agents.
