The Monarch Money MCP Server integrates with the Monarch Money personal finance platform via Claude Desktop to provide comprehensive financial management capabilities:
Account Management: View linked financial accounts with balances, access investment holdings, and refresh account data from institutions.
Transaction Management: Fetch transactions with filtering by date and account, create new transactions, and update existing ones.
Financial Analysis: Access budget information, track spending vs budgets, and perform cashflow analysis over specified date ranges.
Secure Authentication: One-time setup with MFA support, secure session persistence, and encrypted session files.
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., "@monarch-mcp-server show me my last 30 transactions"
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.
A Model Context Protocol (MCP) server for integrating with the Monarch Money personal finance platform. This server provides seamless access to your financial accounts, transactions, budgets, and analytics through Claude Desktop and Claude Code.
My MonarchMoney referral: https://www.monarchmoney.com/referral/ufmn0r83yf?r_source=share
Built with the MonarchMoneyCommunity Python library - An actively maintained community fork of the Monarch Money API with full MFA support.
Clone this repository:
git clone https://github.com/robcerda/monarch-mcp-server.git
cd monarch-mcp-serverInstall dependencies:
Using uv (recommended):
uv sync --locked--locked installs exactly what uv.lock pins, verified against the
hashes it records, and refuses to re-resolve. Without it, uv sync is free
to pick up whatever versions happen to satisfy the ranges today.
Using pip:
pip install -r requirements-lock.txt --require-hashes
pip install -e . --no-depsrequirements-lock.txt is generated from uv.lock and pins every transitive
dependency with hashes, so --require-hashes gives the pip path the same
guarantee as the uv one. --no-deps on the second command stops pip
re-resolving what the first command just pinned.
pip install -r requirements.txt still works and installs exactly the same
set. That file is now a one line include of requirements-lock.txt, kept so
existing setups and scripts do not break. The pins moved out of it because a
root requirements.txt gets resolved as an independent manifest, which had
started producing a pinned set that disagreed with uv.lock.
Configure Claude Desktop: Add this to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"Monarch Money": {
"command": "/opt/homebrew/bin/uv",
"args": [
"run",
"--locked",
"--project",
"/path/to/your/monarch-mcp-server",
"monarch-mcp-server"
]
}
}
}Important: Replace /path/to/your/monarch-mcp-server with your actual path!
uv run --locked --project resolves dependencies from the repo's
uv.lock, and monarch-mcp-server is the console script declared in
pyproject.toml. --locked matters: without it, a lockfile that has
drifted from pyproject.toml is silently re-resolved against PyPI and the
recorded hashes stop being enforced. With it, drift is a startup error.
Earlier versions of this README used uv run --with 'mcp[cli]', which
builds a fresh unpinned environment on every launch and silently picks up
whatever the newest release happens to be. That is what broke every install
when the MCP SDK published 2.0, and the client only reported it as the
server disconnecting. Pinning the launch to the lockfile means a new
upstream release cannot change what your server runs.
Restart Claude Desktop
OR
Configure Claude Code (CLI): Add this to your Claude Code configuration file:
Global (all projects):
macOS/Linux: ~/.claude.json
Windows: %USERPROFILE%\.claude.json
{
"mcpServers": {
"Monarch Money": {
"command": "/opt/homebrew/bin/uv",
"args": [
"run",
"--locked",
"--project",
"/path/to/your/monarch-mcp-server",
"monarch-mcp-server"
]
}
}
}Project-level (specific directory):
Create .mcp.json in your project directory:
{
"Monarch Money": {
"command": "/opt/homebrew/bin/uv",
"args": [
"run",
"--locked",
"--project",
"/path/to/your/monarch-mcp-server",
"monarch-mcp-server"
]
}
}If installed via pip instead of uv, use:
{
"command": "python",
"args": ["/path/to/your/monarch-mcp-server/src/monarch_mcp_server/server.py"]
}Important: Replace /path/to/your/monarch-mcp-server with your actual path!
Restart Claude Code
Important: For security and MFA support, authentication is done outside of Claude.
Open a terminal and run:
cd /path/to/your/monarch-mcp-server
uv run python login_setup.py # or: python login_setup.pyThe script offers three login paths:
Long-lived sessions, supports SSO accounts, and sidesteps Cloudflare CAPTCHA gates on programmatic login. Steps:
Log in to https://app.monarch.com in Chrome or Firefox.
Open DevTools (F12) → Network tab.
Click any request whose Name starts with graphql (or any request to api.monarch.com).
Scroll to Request Headers, find the cookie: header, and copy the full value.
Save it to the cookie file for your platform (recommended), then re-run the script — it reads the file automatically:
macOS / Linux — ~/.config/monarch-mcp/cookie.txt (respects $XDG_CONFIG_HOME):
mkdir -p ~/.config/monarch-mcp
# paste the cookie value into the file with your editor, then:
chmod 600 ~/.config/monarch-mcp/cookie.txtWindows — %APPDATA%\monarch-mcp\cookie.txt:
New-Item -ItemType Directory -Force "$env:APPDATA\monarch-mcp" | Out-Null
notepad "$env:APPDATA\monarch-mcp\cookie.txt" # paste the cookie value, save, closeFiles under your user profile are already ACL-restricted to your account on Windows; no chmod equivalent is needed for typical single-user machines.
To use a different location on any platform, set the MONARCH_MCP_COOKIE_FILE environment variable to the full path.
Alternatively, paste the value at the interactive prompt — but note that
POSIX terminals silently truncate pasted input at the canonical-mode
buffer limit (MAX_CANON, 1024 bytes on macOS/Linux), and real Monarch
cookie headers are usually longer than that, so the prompt path fails
with a confusing auth error for most users. The cookie file has no
length limit and survives repo updates.
The script verifies the cookies against the live API before saving them to your system keyring. The cookie file is only read at setup time; the running MCP server uses the keyring session.
Standard interactive login. The script handles:
Email verification codes (Monarch may send one for a new device session even when MFA is off).
TOTP MFA codes if you have MFA enabled.
Cloudflare CAPTCHA detection: if Monarch blocks programmatic login, the script tells you to switch to option 1.
The resulting long-lived session token is saved to your system keyring.
Kept for users with an existing token captured before the May 2026 API change. Monarch may no longer accept token-only auth on the GraphQL endpoint; if the verification call returns 401, fall back to option 1.
Once authenticated, use these tools directly in Claude Desktop or Claude Code:
get_accounts - View all your financial accounts
get_transactions - Recent transactions with filtering
get_budgets - Budget information and spending
get_cashflow - Income/expense analysis
Related MCP server: monarch-mcp
Get Accounts: View all linked financial accounts with balances and institution info
Get Account Holdings: See securities and investments in investment accounts
Refresh Accounts: Request real-time data updates from financial institutions
Get Transactions: Fetch transaction data with filtering by date, account, and pagination
Create Transaction: Add new transactions to accounts
Update Transaction: Modify existing transactions (amount, description, category, date)
Get Categories: List all transaction categories with groups, icons, and metadata
Get Category Groups: View category groups with their associated categories
Get Transactions Needing Review: Find transactions that need attention (uncategorized, no notes, flagged)
Set Transaction Category: Assign a category to a transaction
Update Transaction Notes: Add or update notes on transactions (great for receipt links)
Mark Transaction Reviewed: Clear the needs_review flag on transactions
Bulk Categorize Transactions: Apply a category to multiple transactions at once
Get Tags: List all available tags with colors and usage counts
Set Transaction Tags: Apply tags to a transaction
Create Tag: Create a new tag with custom name and color
Search Transactions: Comprehensive search with filters for merchant, category, account, tags, date ranges, and amounts
Get Transaction Details: Retrieve complete details for a single transaction
Delete Transaction: Remove a transaction
Get Recurring Transactions: View upcoming recurring transactions
Get Transaction Rules: List all auto-categorization rules
Create Transaction Rule: Create rules with merchant/amount conditions to auto-categorize
Update Transaction Rule: Modify existing rules
Delete Transaction Rule: Remove a rule
Get Merchant: View a merchant's details including recurring transaction stream configuration
Update Merchant: Modify a merchant's name and/or recurring stream settings (frequency, amount, base date)
Review Recurring Stream: Accept, ignore, or reset recurring transaction streams detected by Monarch
Get Transaction Splits: View how a transaction has been split into parts
Split Transaction: Divide a single transaction into multiple parts with different categories or merchants
Get Budgets: Access budget information including spent amounts and remaining balances by category
Set Budget Amount: Create or modify budget amounts for any category or category group
Get Net Worth: Track total net worth over time with daily snapshots and trend analysis
Get Account Balance History: View historical balance data for any account
Get Net Worth by Account Type: See net worth breakdown across account types (checking, savings, investments, etc.)
Get Cashflow: Analyze financial cashflow over specified date ranges with income/expense breakdowns
Get Transactions Summary: Quick high-level statistics about your transactions
Get Spending Summary: Spending breakdown by category with totals
One-Time Setup: Authenticate once, use for weeks/months
Email OTP Support: Handles Monarch's email verification flow for new devices/sessions
MFA Support: Full support for two-factor authentication
SSO/Google sign-in: Use monarch_login_with_token to paste a session token from your browser
Session Persistence: No need to re-authenticate frequently
Secure: Credentials never pass through Claude
All 58 registered tools. Required parameters are listed first, optional ones are marked with a trailing question mark. This table is generated from the live tool registry and the functions' signatures, so it does not drift.
Tool | Description | Parameters |
| Add a tag to a transaction, preserving any tags already on it |
|
| Apply the same category to multiple transactions at once |
|
| Assign a category to a transaction |
|
| Report the stored session and its auth mode | None |
| Create a new transaction in Monarch Money |
|
| Create a new transaction category |
|
| Create a new transaction auto-categorization rule |
|
| Create a new transaction tag |
|
| Diagnose session loading problems | None |
| Delete a transaction from Monarch Money |
|
| Delete a transaction rule |
|
| Get historical balance data for a specific account |
|
| Get investment holdings for a specific account |
|
| Report the health of each linked institution connection |
|
| Get all financial accounts from Monarch Money | None |
| Get budget information from Monarch Money |
|
| Get cashflow analysis from Monarch Money |
|
| Get spending trends over time, broken down by category and month |
|
| Get a single category's details including budget amounts for a month |
|
| Get the debt paydown plan and the accounts feeding it |
|
| Show a goal's budgeted contributions, broken down by funding account |
|
| List Monarch savings and debt-paydown goals | None |
| Get a merchant's details including recurring transaction stream configuration |
|
| Get net worth history over time |
|
| Get net worth breakdown by account type over time |
|
| Get upcoming recurring transactions |
|
| Get a spending summary broken down by category, category group, and merchant |
|
| Get all available transaction categories from Monarch Money | None |
| Get all transaction category groups (parent groupings for categories) | None |
| Get full details for a specific transaction |
|
| Get all transaction auto-categorization rules from Monarch Money | None |
| Get the splits for a transaction |
|
| Get all available transaction tags from Monarch Money | None |
| Get transactions from Monarch Money |
|
| Get transactions that need review based on various criteria |
|
| Get a high-level summary of transactions | None |
| Mark a transaction as reviewed (clears the needs_review flag) |
|
| Sign in via a secure form in the client UI | None |
| Sign in with a browser copied session token | None |
| Clear the stored session and drop the cached client | None |
| Report who is signed in and what the account's plan entitles it to | None |
| Request account data refresh from financial institutions |
|
| Move a transaction rule to a new position in the evaluation order |
|
| Set the review status of a recurring transaction stream |
|
| Search and filter transactions with comprehensive filtering options |
|
| Set or update a budget amount for a category or category group |
|
| Set the budgeted monthly contribution to a goal from one funding account |
|
| Set tags on a transaction |
|
| Get setup instructions | None |
| Split a transaction into multiple parts with different categories/merchants |
|
| Update an account's name, balance, type or visibility settings |
|
| Update an existing category's settings |
|
| Update a merchant's name and/or recurring transaction stream settings |
|
| Update a savings goal's target or monthly contribution |
|
| Update an existing transaction in Monarch Money |
|
| Update the notes/memo for a transaction |
|
| Update an existing transaction rule |
|
| Upload corrected balance snapshots for an account |
|
Use get_accounts to show me all my financial accountsShow me my last 50 transactions using get_transactions with limit 50get_transactions returns a JSON object with tool, args, count, total_count, truncated, search, and data so large agent-tools/<uuid>.txt responses are self-describing. Transaction rows live in data and include original_statement / plaid_description when Monarch provides the underlying Plaid statement text, plus currency, direction, direction_source, transaction_type, category_group, and category_group_id when those values can be derived from Monarch response data. When Monarch's server-side search errors or returns no rows, wide_search scans recent transactions locally across merchant, original statement, description, notes, category, account, and tags.
Use get_budgets to show my current budget statusSet my grocery budget to $600 for this month using set_budget_amountSet my entertainment budget to $150 and apply it to all future months using set_budget_amount with apply_to_future=trueShow my net worth trend for the past year using get_net_worthShow me how my savings account balance has changed over time using get_account_balance_historyShow my net worth breakdown by account type using get_net_worth_by_account_typeGet my cashflow for the last 3 months using get_cashflowShow me all available categories using get_transaction_categoriesShow me transactions from the last 7 days that need review using get_transactions_needing_reviewCategorize these three transactions as "Groceries" using bulk_categorize_transactionsAdd the "Tax Deductible" tag to this transaction using set_transaction_tagsFind all Amazon transactions from the last month using search_transactionsShow me my upcoming recurring transactions using get_recurring_transactionsCreate a rule to automatically categorize Amazon transactions as "Shopping" using create_transaction_ruleSplit this $100 Costco transaction into $60 for Groceries and $40 for Household using split_transactionGive me a quick summary of my transactions using get_transactions_summaryShow my spending breakdown by category for last month using get_spending_summaryUpdate PennyMac's recurring stream to $1,460.93 monthly using update_merchantApprove the Netflix recurring stream using review_recurring_streamAll dates should be in YYYY-MM-DD format (e.g., "2024-01-15")
Transaction amounts: positive for income, negative for expenses
If you see "Authentication needed" errors:
Run the setup command: cd /path/to/your/monarch-mcp-server && python login_setup.py (or uv run python login_setup.py)
Restart Claude Desktop or Claude Code
Try using a tool like get_accounts
Monarch may require an email one-time code for a new device or session, even if MFA is not enabled. If you see an email-code prompt:
Check the email address on your Monarch account
Enter the one-time code in login_setup.py
Let the script finish so it can save the reusable token to your system keyring
If your session dies quickly (under a couple of hours), the most common cause is that Monarch returned a short-lived token. The login script now requests trusted_device=True and rejects any short-lived token, so a fresh login produces a long-lived session. If you re-run login_setup.py and the issue persists, switch to option 1 (browser cookies); cookie sessions track the lifetime of the underlying browser login.
If login_setup.py reports "Programmatic login is blocked by Cloudflare CAPTCHA", choose option 1 (browser cookies) instead. Email/password POSTs to Monarch's login endpoint are sometimes gated by Cloudflare for unfamiliar IPs or rapid retries; cookie-based auth bypasses that endpoint entirely.
'Context' object has no attribute 'elicit'The monarch_login and monarch_login_with_token tools require the MCP Python SDK 1.10.0 or newer (released June 2025). If your environment cached an older mcp install, refresh it:
uv cache clean mcpThen fully quit and reopen Claude Desktop or Claude Code so it relaunches the server with a fresh resolution. As a fallback while you upgrade, run python login_setup.py from the repo to authenticate via the terminal.
"No valid session found": Run python login_setup.py (or uv run python login_setup.py)
"Monarch sent a one-time code to your email": Run python login_setup.py and complete email verification
"Invalid account ID": Use get_accounts to see valid account IDs
"Date format error": Use YYYY-MM-DD format for dates
monarch-mcp-server/
├── src/monarch_mcp_server/
│ ├── __init__.py
│ ├── app.py # FastMCP app instance and entry point
│ ├── client.py # Cached MonarchMoney client factory
│ ├── monarch_auth.py # Current Monarch auth compatibility (host, email OTP, device-uuid)
│ ├── secure_session.py # Keyring-backed token storage (file fallback)
│ ├── server.py # Backward-compatibility shim re-exporting the tools
│ └── tools/ # MCP tools grouped by domain (accounts, transactions, budgets, …)
├── login_setup.py # Terminal authentication script
├── pyproject.toml # Project configuration
├── requirements-lock.txt # Generated from uv.lock, hash pinned
└── README.md # This documentationSession tokens are stored securely in the system keyring (with an automatic file fallback for environments without a keyring backend)
The device-uuid captured at login is stored alongside the token so it reloads cleanly
Sessions persist across Claude Desktop and Claude Code restarts
No need for frequent re-authentication
Credentials never transmitted through Claude Desktop or Claude Code
MFA/2FA fully supported
Email verification codes are handled only in the terminal setup script
Session tokens are stored in the system keyring
Authentication handled in secure terminal environment
Set MONARCH_MCP_READ_ONLY=1 in the server's environment and the mutating
tools are never registered. They do not appear in the tool list and cannot be
called at all, which is stronger than an approval prompt: a model that was
talked into a write by a merchant name or memo it read back cannot invoke a
tool that is not there.
{
"mcpServers": {
"Monarch Money": {
"command": "/opt/homebrew/bin/uv",
"args": ["run", "--project", "/path/to/your/monarch-mcp-server", "monarch-mcp-server"],
"env": { "MONARCH_MCP_READ_ONLY": "1" }
}
}
}This leaves 30 of the 58 tools available, covering everything that reads.
Read only is off by default, so existing setups are unaffected. Note that it
also removes the login and logout tools, since those change durable state, so
authenticate with login_setup.py before enabling it.
These tools mutate your Monarch data. The list is every registered tool that writes, checked against the source rather than maintained by hand:
Accounts: update_account
Transactions: create_transaction, update_transaction, delete_transaction, categorize_transaction, update_transaction_notes, mark_transaction_reviewed, bulk_categorize_transactions, split_transaction, upload_account_balance_history
Tags: set_transaction_tags, add_transaction_tag, create_transaction_tag
Rules: create_transaction_rule, update_transaction_rule, delete_transaction_rule, reorder_transaction_rule
Categories and budgets: create_transaction_category, update_category, set_budget_amount
Goals: update_savings_goal, set_goal_contribution
Merchants: update_merchant, review_recurring_stream
Session: monarch_login, monarch_login_with_token, monarch_logout
refresh_accounts is side effecting too, since it posts a refresh request to your institutions, though it does not change your ledger.
Because the LLM can be influenced by data it reads back (a malicious-looking memo or merchant name in a transaction), the safest setup is to configure your MCP client to require manual approval before any mutating tool runs. In Claude Desktop and Claude Code this is the default behavior for unknown tools; keep it that way for the tools listed above rather than allow-listing them.
bulk_categorize_transactions, upload_account_balance_history, update_account and update_category accept a dry_run=True argument that returns the planned changes without executing them, useful for previewing before approving.
update_category additionally requires confirm_rollover_reset=True before rollover_start_month or rollover_starting_balance will be applied. Those two restart a category's rollover period and discard the balance accumulated in it, which cannot be undone, so they cannot ride along unnoticed in a call that otherwise reads like a rename.
This MCP server is built on top of the MonarchMoneyCommunity Python library, an actively maintained community fork of the original MonarchMoney library by @hammem. The community fork provides:
Updated API endpoints for Monarch Money's current domain
Secure authentication with MFA support
Comprehensive API coverage for Monarch Money
Session management and persistence
Thank you to @hammem for creating and maintaining this essential library!
MIT License
For issues:
Check authentication with check_auth_status
Run the setup command again: cd /path/to/your/monarch-mcp-server && python login_setup.py
Check error logs for detailed messages
Ensure Monarch Money service is accessible
To update the server:
Pull latest changes from repository
Restart Claude Desktop or Claude Code
Re-run authentication if needed: python login_setup.py
Check if already authenticated with Monarch Money.
| 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 the tool checks authentication status but doesn't describe what happens if authentication fails (e.g., returns false, throws error), what data is returned, or any side effects. This leaves gaps for a tool that likely informs subsequent actions.
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 no wasted words. It front-loads the core purpose ('Check if already authenticated') and specifies the context ('with Monarch Money'), making it easy to scan and understand immediately.
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's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavior, output, or integration with sibling tools. For a no-param tool, this might suffice, but the absence of output schema means the description should ideally hint at return values.
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 schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, aligning with the schema. A baseline of 4 is applied as it efficiently handles the lack of parameters without unnecessary detail.
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: 'Check if already authenticated with Monarch Money.' It specifies the verb ('check') and resource ('authentication status'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'setup_authentication' beyond the implied read-only vs. setup 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 on when to use this tool versus alternatives. It doesn't mention prerequisites, timing (e.g., before other operations), or contrast with sibling tools like 'setup_authentication' for unauthenticated cases. Usage is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new transaction in Monarch Money.
Args:
account_id: The account ID to add the transaction to
amount: Transaction amount (positive for income, negative for expenses)
description: Transaction description
date: Transaction date in YYYY-MM-DD format
category_id: Optional category ID
merchant_name: Optional merchant name
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | ||
| amount | Yes | ||
| category_id | No | ||
| date | Yes | ||
| description | Yes | ||
| merchant_name | No |
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 creation operation but doesn't cover important aspects like required permissions, whether the transaction is immediately posted or pending, error conditions, or what happens on success. The description lacks behavioral context beyond the basic action.
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 well-structured with a clear purpose statement followed by parameter explanations. It's appropriately sized and front-loaded, though the parameter explanations could be slightly more concise (e.g., combining optional parameters). Every sentence adds value.
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 6 parameters with 0% schema coverage and no output schema, the description does a good job explaining parameters but lacks completeness for a mutation tool. It doesn't cover authentication requirements, error handling, or what the tool returns. The parameter explanations help, but behavioral context is insufficient for full understanding.
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 description adds significant value beyond the input schema, which has 0% description coverage. It explains each parameter's purpose: 'account_id: The account ID to add the transaction to', 'amount: Transaction amount (positive for income, negative for expenses)', etc. This clarifies semantics that aren't evident from schema titles alone, especially for 'amount' with its sign convention.
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: 'Create a new transaction in Monarch Money.' It specifies the verb ('Create') and resource ('transaction'), though it doesn't explicitly differentiate from sibling tools like 'get_transactions' beyond the obvious create vs. get 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 on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication status), constraints, or compare it to sibling tools like 'get_transactions' or 'get_cashflow' for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Debug session loading issues.
| 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. 'Debug session loading issues' implies this is a diagnostic/read-only operation, but doesn't specify whether it performs any mutations, what permissions are required, what output format to expect, or whether it has side effects. For a debugging tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 at just 4 words. It's front-loaded with the core purpose and contains zero wasted words. While it's under-specified in terms of content, as a piece of writing it's maximally efficient and well-structured for its limited information content.
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 this is a debugging tool with no annotations and no output schema, the description is insufficiently complete. Debugging tools typically need to explain what diagnostic information is provided, what format results come in, and what specific 'session loading issues' are addressed. The description leaves too many open questions about what the tool actually does and returns.
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 with 100% schema description coverage, so the schema already fully documents the parameter situation. The description doesn't need to compensate for any parameter gaps. However, it could potentially mention that no parameters are required, which would be a minor enhancement. Baseline for 0 parameters with full schema coverage is 4.
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 'Debug session loading issues' is tautological - it essentially restates the tool name 'debug_session_loading' with minimal elaboration. While it indicates the tool is for debugging, it doesn't specify what 'session loading' refers to, what debugging actions are performed, or what resources are involved. It's better than just 'Debug' but still lacks specific verb+resource clarity.
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. There's no mention of prerequisites, triggers, or context for when session loading debugging is needed. Given there are 7 sibling tools including authentication-related ones like 'check_auth_status' and 'setup_authentication', the description should help differentiate when to debug sessions versus checking or setting up authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get investment holdings for a specific account.
Args:
account_id: The ID of the investment account
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes |
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 'Get' which implies a read operation, but doesn't mention permissions required, rate limits, pagination, error conditions, or what the return format looks like. This leaves significant gaps for a tool that presumably accesses sensitive financial data.
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 appropriately concise with two sentences that directly address purpose and parameters. The structure is front-loaded with the core purpose first. No wasted words, though the formatting with 'Args:' could be slightly more polished.
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 accessing investment holdings with no annotations and no output schema, the description is insufficient. It doesn't explain what 'holdings' includes (stocks, bonds, cash), return format, authentication requirements, or error handling. Given the financial context and lack of structured documentation, more completeness 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?
Schema description coverage is 0%, so the description must compensate. It provides basic semantics for the single parameter ('The ID of the investment account'), which adds value beyond the schema's minimal documentation. However, it doesn't explain format requirements, validation rules, or where to find account IDs, leaving room for improvement.
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 resource 'investment holdings for a specific account', making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_accounts' or 'get_transactions' which might also retrieve account-related data, so it doesn't reach the highest score.
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 'get_accounts' or 'get_transactions'. It mentions 'specific account' but doesn't clarify prerequisites, exclusions, or comparative use cases with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all financial accounts from Monarch Money.
| 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. It states it 'gets' accounts but doesn't describe what 'all' entails (e.g., pagination, filtering options), return format, error conditions, or rate limits. 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 zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'all financial accounts' includes (e.g., types, fields returned), behavioral aspects like authentication requirements, or how results are structured, leaving significant gaps for agent understanding.
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 with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't add parameter details, but with no parameters, a baseline of 4 is appropriate as there's nothing to compensate for.
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 ('all financial accounts from Monarch Money'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'get_account_holdings' or 'get_transactions', which likely retrieve related but different financial data.
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 (e.g., authentication status), context for use, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get budget information from Monarch Money.
| 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 the tool retrieves budget information but doesn't describe what 'budget information' includes, whether it's read-only, if it requires authentication, or any rate limits. This leaves significant gaps for a tool that likely interacts with financial data.
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 directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded, making it easy for an agent 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 for a tool that likely returns financial data. It doesn't explain what 'budget information' entails (e.g., categories, amounts, time periods), authentication requirements, or error handling, leaving the agent with incomplete context for proper 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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, but that's appropriate here. A baseline of 4 is applied as it's complete for a parameterless tool.
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 resource ('budget information from Monarch Money'), making the tool's purpose immediately understandable. It doesn't differentiate from siblings like 'get_cashflow' or 'get_transactions', but it's specific enough to identify its 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 'get_cashflow' or 'get_transactions'. It lacks context about prerequisites (e.g., authentication status) or typical use cases, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cashflow analysis from Monarch Money.
Args:
start_date: Start date in YYYY-MM-DD format
end_date: End date in YYYY-MM-DD format
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | ||
| start_date | No |
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 states this is a 'Get' operation, implying read-only behavior, but doesn't disclose any behavioral traits such as authentication requirements, rate limits, data freshness, or what constitutes a cashflow analysis. This leaves significant gaps for a tool with no 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 appropriately sized with two sentences: one stating the purpose and one listing parameters. It's front-loaded with the main function, though the parameter listing could be integrated more smoothly. There's minimal waste, earning its place efficiently.
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 financial analysis tools, no annotations, no output schema, and 0% schema coverage, the description is incomplete. It lacks details on authentication needs, return format, error handling, and how cashflow analysis is defined, making it inadequate for informed tool selection and 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?
The description adds meaningful semantics by specifying the date format (YYYY-MM-DD) for both parameters, which compensates for the 0% schema description coverage. However, it doesn't explain default behaviors (e.g., what happens if dates are null) or constraints like valid date ranges, leaving some ambiguity.
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 resource 'cashflow analysis from Monarch Money', providing a specific purpose. However, it doesn't distinguish this tool from sibling tools like 'get_transactions' or 'get_accounts', which might also retrieve financial data, so it doesn't fully differentiate from alternatives.
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 'get_transactions' or 'get_accounts', nor does it mention prerequisites such as authentication status. It only lists parameters without context on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get transactions from Monarch Money.
Args:
limit: Number of transactions to retrieve (default: 100)
offset: Number of transactions to skip (default: 0)
start_date: Start date in YYYY-MM-DD format
end_date: End date in YYYY-MM-DD format
account_id: Specific account ID to filter by
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | No | ||
| end_date | No | ||
| limit | No | ||
| offset | No | ||
| start_date | No |
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 the tool retrieves transactions but fails to describe critical behaviors: whether this is a read-only operation, what the return format looks like (e.g., list of objects with fields), pagination behavior beyond limit/offset, error conditions, or rate limits. The description is minimally functional but leaves the agent guessing about important operational aspects.
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 structured and concise: a clear purpose statement followed by a well-organized parameter list with brief but complete explanations. Every sentence earns its place, with no redundant or vague language. The information is front-loaded with the core purpose immediately stated.
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's moderate complexity (5 parameters, no output schema, no annotations), the description is partially complete. It excels at parameter documentation but lacks critical context about return values, authentication requirements, error handling, and differentiation from sibling tools. The absence of an output schema means the description should ideally describe what the tool returns, but it doesn't, leaving a significant gap for agent understanding.
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 description provides excellent parameter semantics that fully compensate for the 0% schema description coverage. For all 5 parameters, it explains their purpose (e.g., 'limit: Number of transactions to retrieve'), provides format details (e.g., 'YYYY-MM-DD format'), and indicates defaults. This adds substantial value beyond the bare schema, which only lists titles without explanations.
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 as 'Get transactions from Monarch Money' with a specific verb ('Get') and resource ('transactions'), making it immediately understandable. However, it doesn't distinguish this tool from potential sibling tools like 'get_cashflow' or 'get_accounts' that might also retrieve financial data, preventing a perfect score.
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 'get_cashflow' or 'get_accounts' from the sibling list. It also doesn't mention prerequisites such as authentication status, which is relevant given the 'setup_authentication' and 'check_auth_status' siblings. The parameter documentation implies usage for filtering transactions but offers no strategic context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request account data refresh from financial institutions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description adds little beyond the name. Lacks disclosure of side effects (mutation), asynchronicity, or impact on account data. Only reveals that a refresh is requested, but not the consequences.
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 with no extraneous words. While concise, the brevity sacrifices informational value. Could be expanded 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?
Given zero parameters, no output schema, and no annotations, the description is too minimal. For a tool that initiates a refresh (likely async with side effects), missing details on outcome, latency, and notifications.
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 and schema coverage is 100%, so description need not add param info. Baseline score of 4 applies as per guidelines for zero 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?
Description clearly states action: requesting a data refresh from financial institutions. Verb+resource is specific and distinguishes from siblings like get_accounts (retrieval) and create_transaction (creation). No ambiguity.
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 (e.g., get_accounts for current data) or prerequisites (e.g., auth status). Missing context on execution timing or frequency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get instructions for setting up secure authentication with Monarch Money.
| 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 mentions 'Get instructions' but doesn't clarify what these instructions entail (e.g., step-by-step guides, API keys, OAuth flows), whether the tool is read-only or involves setup actions, or any potential side effects like rate limits or authentication requirements. This leaves significant gaps in understanding the tool's behavior.
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 directly states the tool's purpose without any fluff or redundant information. It is front-loaded and appropriately sized for a simple tool, making it easy for an agent to parse and understand 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 tool's simplicity (0 parameters, no annotations, no output schema), the description is adequate but has clear gaps. It explains what the tool does but lacks details on behavioral aspects like what the instructions include or how they should be used. For a tool related to authentication setup, more context on output format or usage steps would enhance completeness, but it meets the minimum viable threshold.
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 input schema has 100% description coverage (though empty). The description doesn't need to add parameter details, as there are none to document. It appropriately focuses on the tool's purpose without unnecessary parameter explanations, meeting the baseline for a parameterless tool.
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 a specific verb ('Get instructions') and resource ('setting up secure authentication with Monarch Money'), making it immediately understandable. However, it doesn't explicitly differentiate itself from sibling tools like 'check_auth_status', which might also relate to authentication processes, leaving room for potential confusion about when to use each.
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, such as 'check_auth_status' for verifying authentication status or other tools for data retrieval. It lacks context about prerequisites, timing, or exclusions, leaving the agent to infer usage based solely on the tool name and description without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing transaction in Monarch Money.
Args:
transaction_id: The ID of the transaction to update
amount: New transaction amount
description: New transaction description
category_id: New category ID
date: New transaction date in YYYY-MM-DD format
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| amount | No | ||
| category_id | No | ||
| description | No | ||
| transaction_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description does not disclose side effects (e.g., what if transaction_id is invalid), authentication needs, or reversibility. Minimal behavioral context beyond the action itself.
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?
Two clear sentences plus a well-structured Args list. No filler, information is front-loaded and easy to parse.
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?
Covers basic action and parameters, but lacks return value description or error handling. With no output schema, the agent is left guessing about response format. Adequate but incomplete.
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?
Description adds meaning beyond the schema by specifying 'New transaction amount', etc., and providing date format (YYYY-MM-DD). Despite schema coverage metric of 0%, the Args list enriches parameter understanding.
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 'Update an existing transaction in Monarch Money' – specific verb, resource, and platform. Distinct from sibling tools like create_transaction and get_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?
No guidance on when to use this tool vs alternatives (e.g., create_transaction). No mention of prerequisites or conditions for updating.
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.
v1.0.0check_auth_statuscreate_transactiondebug_session_loadingget_account_holdingsget_accountsget_budgetsget_cashflowget_transactionsrefresh_accountssetup_authenticationupdate_transactionScored across 11 tools
Tools are mostly distinct: transactions, accounts, budgets, cashflow, and holdings each target different resources. However, get_accounts and get_account_holdings could be confused despite the holding-specific focus, and debug_session_loading is vaguely defined and might overlap with auth-status checks.
The majority follow a consistent verb_noun pattern (get_, create_, update_, refresh_), but debug_session_loading breaks the convention (noun-based) and setup_authentication/check_auth_status use a slightly different style, causing minor inconsistency.
Eleven tools is well-scoped for a personal finance integration. Each tool covers a distinct aspect (read accounts, budgets, cashflow, transactions, holdings, write transactions, auth, refresh) without unnecessary redundancy, making the set feel complete yet focused.
The surface covers core finance operations: listing accounts, budgets, cashflow, transactions, and holdings, plus create/update for transactions and refresh. Missing delete_transaction is a minor gap, and there's no tool for managing categories or accounts directly, but the primary workflows are covered.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
The official MCP Server for the Mux API
Query your real net worth, spending, transactions, budgets and portfolio from any MCP client.
MCP server for Modern Treasury — payment orders, transactions, counterparties and ledgers.
