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 pip:
pip install -r requirements.txt
pip install -e .Using uv (alternative):
uv syncConfigure 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",
"--with",
"mcp[cli]",
"--with-editable",
"/path/to/your/monarch-mcp-server",
"mcp",
"run",
"/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 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",
"--with",
"mcp[cli]",
"--with-editable",
"/path/to/your/monarch-mcp-server",
"mcp",
"run",
"/path/to/your/monarch-mcp-server/src/monarch_mcp_server/server.py"
]
}
}
}Project-level (specific directory):
Create .mcp.json in your project directory:
{
"Monarch Money": {
"command": "/opt/homebrew/bin/uv",
"args": [
"run",
"--with",
"mcp[cli]",
"--with-editable",
"/path/to/your/monarch-mcp-server",
"mcp",
"run",
"/path/to/your/monarch-mcp-server/src/monarch_mcp_server/server.py"
]
}
}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 Terminal and run:
Using python:
cd /path/to/your/monarch-mcp-server
python login_setup.pyUsing uv:
cd /path/to/your/monarch-mcp-server
uv run python login_setup.pyFollow the prompts:
Enter your Monarch Money email and password
Provide 2FA code if you have MFA enabled
Session will be saved automatically
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 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
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
Tool | Description | Parameters |
| Get setup instructions | None |
| Check authentication status | None |
| Get all financial accounts | None |
| Get transactions with filtering |
|
| Get budget information |
|
| Set budget for a category |
|
| Get cashflow analysis |
|
| Get net worth history |
|
| Get account balance history |
|
| Get net worth by account type |
|
| Get investment holdings |
|
| Create new transaction |
|
| Update existing transaction |
|
| Request account data refresh | None |
| List all transaction categories | None |
| List category groups with categories | None |
| Get transactions needing review |
|
| Set category on a transaction |
|
| Update notes on a transaction |
|
| Mark transaction as reviewed |
|
| Categorize multiple transactions |
|
| List all tags | None |
| Set tags on a transaction |
|
| Create a new tag |
|
| Search transactions with filters |
|
| Get details of a transaction |
|
| Delete a transaction |
|
| Get recurring transactions | None |
| List auto-categorization rules | None |
| Create an auto-categorization rule |
|
| Update an existing rule |
|
| Delete a rule |
|
| Get splits for a transaction |
|
| Split a transaction into parts |
|
| Get high-level transaction statistics | None |
| Get spending breakdown by category |
|
Use get_accounts to show me all my financial accountsShow me my last 50 transactions using get_transactions with limit 50Use 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_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 over $50 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_summaryAll 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
Sessions last for weeks, but if expired:
Run the same setup command again: python login_setup.py (or uv run python login_setup.py)
Enter your credentials and 2FA code
Session will be refreshed automatically
"No valid session found": Run python login_setup.py (or uv run python login_setup.py)
"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
│ └── server.py # Main server implementation
├── login_setup.py # Email/password authentication script
├── pyproject.toml # Project configuration
├── requirements.txt # Dependencies
└── README.md # This documentationSessions are stored securely in .mm/mm_session.pickle
Automatic session discovery and loading
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
Session files are encrypted
Authentication handled in secure terminal environment
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. Dates show when Glama detected each change.
v1.0.0check_auth_statuscreate_transactiondebug_session_loadingget_account_holdingsget_accountsget_budgetsget_cashflowget_transactionsrefresh_accountssetup_authenticationupdate_transactionMost tools have distinct purposes targeting different financial data types (accounts, transactions, budgets, cashflow, holdings), but 'debug_session_loading' overlaps with authentication tools as it addresses session issues rather than core financial operations, creating some ambiguity in the set.
Tools follow a consistent verb_noun pattern (e.g., get_accounts, create_transaction, check_auth_status) with clear action-object naming, though 'debug_session_loading' uses a less conventional 'debug_' prefix and 'setup_authentication' uses 'setup_' instead of a verb like 'configure', causing minor deviations.
With 9 tools, the count is well-scoped for a personal finance server, covering authentication, core financial data retrieval (accounts, transactions, budgets, cashflow, holdings), and transaction creation without being overwhelming or too sparse.
The server provides good read coverage for financial data and transaction creation, but lacks update/delete operations for transactions, accounts, or budgets, and has no investment-specific actions beyond holdings retrieval, leaving notable gaps in lifecycle management for the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/robcerda/monarch-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
