The Expense Tracker MCP Server enables comprehensive personal expense management through natural language interactions with Claude Desktop, storing data in a SQLite database.
Core Capabilities:
Add Expenses - Record expenses with date, amount, category, optional subcategory, and notes
List Expenses - View expenses within specific date ranges
Update Expenses - Modify existing expenses by ID, changing any combination of fields
Delete Expenses - Remove expenses using flexible criteria (ID, date, category, subcategory, amount, note, or date ranges)
Summarize Expenses - Get aggregated spending summaries grouped by category for specific periods, with optional category filtering
View Categories - Access predefined expense categories (food, transport, entertainment, utilities, healthcare)
Deployment Options:
Direct Remote Access - Connect to pre-deployed server instantly (Claude Pro only)
Local Proxy - Run a local proxy to remote server (works with Claude Free)
Full Local Installation - Complete control with local database storage for maximum privacy
Stores and manages personal expense data in a SQLite database, including adding, updating, deleting, listing, and summarizing expenses by category with persistent storage.
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., "@Expense Tracker MCP Server show me my expenses from this month"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for tracking personal expenses with SQLite database storage. This server integrates with Claude Desktop to provide expense management capabilities through natural language.
✅ Add, update, and delete expenses
✅ List expenses by date range
✅ Summarize expenses by category
✅ Flexible deletion by multiple criteria
✅ Predefined expense categories
✅ SQLite database for persistent storage
✅ Local and remote deployment options
Related MCP server: ExpenseTracker MCP Server
Choose the setup method that works best for you:
⚠️ Requires Claude Pro subscription - Direct URL connections are a Pro feature.
Connect directly to the deployed remote server without any local setup:
Open Claude Desktop configuration file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Add this configuration:
{
"mcpServers": {
"expense-tracker": {
"url": "https://boiling-aqua-trout.fastmcp.app/mcp"
}
}
}Restart Claude Desktop
Start tracking expenses immediately! 🎉
Note: This remote server is hosted on FastMCP Cloud. Your data is stored on the remote server.
Don't have Claude Pro? Use Option 2 below to connect via a local proxy server!
✅ Works with Claude Free plan! Run a local MCP server that proxies requests to the remote server. This is the way to access remote MCP servers if you don't have Claude Pro.
Use cases:
Connect to remote servers on Claude Free plan
Add custom logging or middleware
Run locally while using remote data
Extend functionality with additional features
Install uv (if not already installed):
Windows (PowerShell):
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"macOS/Linux:
curl -LsSf https://astral.sh/uv/install.sh | shCreate a new project:
mkdir expense-tracker-proxy
cd expense-tracker-proxy
uv init .Install FastMCP:
uv add fastmcpCreate proxy server (main.py):
from fastmcp import FastMCP
mcp = FastMCP.as_proxy(
"https://boiling-aqua-trout.fastmcp.app/mcp",
name="expense tracker remote proxy server"
)
if __name__ == "__main__":
mcp.run()Configure Claude Desktop:
{
"mcpServers": {
"expense-tracker-proxy": {
"command": "uv",
"args": [
"--directory",
"C:/Users/YOUR_USERNAME/path/to/expense-tracker-proxy",
"run",
"main.py"
]
}
}
}Important: Replace the path with your actual project directory.
Restart Claude Desktop
Benefits of Proxy Approach:
Add custom logging or middleware
Modify requests/responses before forwarding
Run locally but leverage remote infrastructure
Easy to extend with additional features
For those who want full control, privacy, and the ability to modify the core server logic.
Python 3.10 or higher
uv package manager
Claude Desktop app
Windows (PowerShell):
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"macOS/Linux:
curl -LsSf https://astral.sh/uv/install.sh | sh# Clone this repository
git clone https://github.com/Sudhanvaha/expense-tracker-mcp-server.git
cd expense-tracker-mcp-server
# OR create from scratch
mkdir expense-tracker-mcp-server
cd expense-tracker-mcp-server
uv init .# Install required packages
uv add fastmcpCopy the full main.py code from this repository into your project.
# Run the server
uv run main.pyOpen Claude Desktop configuration file (locations mentioned above)
Add the MCP server configuration:
{
"mcpServers": {
"expense-tracker-local": {
"command": "uv",
"args": [
"--directory",
"C:/Users/YOUR_USERNAME/path/to/expense-tracker-mcp-server",
"run",
"main.py"
]
}
}
}Important: Replace the path with your actual project directory path.
Restart Claude Desktop
Once configured (via any method), you can interact with the expense tracker through Claude using natural language:
"Add an expense: $50 for groceries on 2024-12-14"
"Log $25.50 spent on transport today with note 'Uber to office'""Show me all expenses from December 1 to December 14, 2024"
"List my expenses for last week""Update expense ID 5 to $75"
"Change the category of expense 3 to 'entertainment'""Delete expense with ID 5"
"Remove all food expenses from last week"
"Delete expenses in the transport category""Summarize my expenses by category for December 2024"
"What's my total spending on food this month?""What expense categories are available?"
"Show me the list of categories"add_expenseAdd a new expense to the tracker.
Parameters:
date (string): Date in YYYY-MM-DD format
amount (float): Expense amount
category (string): Expense category
subcategory (string, optional): Subcategory
note (string, optional): Additional notes
list_expensesList all expenses within a date range.
Parameters:
start_date (string): Start date (YYYY-MM-DD)
end_date (string): End date (YYYY-MM-DD)
update_expenseUpdate an existing expense (only provided fields will be updated).
Parameters:
cid (int): Expense ID to update
date (string, optional): New date
amount (float, optional): New amount
category (string, optional): New category
subcategory (string, optional): New subcategory
note (string, optional): New note
delete_expenseDelete expenses based on various criteria.
Parameters:
id (int, optional): Delete by ID
date (string, optional): Delete by date
category (string, optional): Delete by category
subcategory (string, optional): Delete by subcategory
amount (float, optional): Delete by amount
note (string, optional): Delete by note
start_date & end_date (strings, optional): Delete by date range
summarize_expensesGet expense summaries grouped by category.
Parameters:
start_date (string): Start date (YYYY-MM-DD)
end_date (string): End date (YYYY-MM-DD)
category (string, optional): Filter by specific category
expense://categoriesReturns the list of available expense categories in JSON format.
CREATE TABLE expenses (
id INTEGER PRIMARY KEY AUTOINCREMENT,
date TEXT NOT NULL,
amount REAL NOT NULL,
category TEXT NOT NULL,
subcategory TEXT DEFAULT '',
note TEXT DEFAULT ''
);For Full Local Installation:
expense-tracker-mcp-server/
├── main.py # MCP server code
├── expense.db # SQLite database (auto-created)
├── categories.json # Categories list (auto-created)
├── pyproject.toml # uv project configuration
└── README.md # This fileFor Proxy Setup:
expense-tracker-proxy/
├── main.py # Proxy server code (5 lines!)
└── pyproject.toml # uv project configurationThe server comes with these default categories:
food
transport
entertainment
utilities
healthcare
You can modify categories.json to add or remove categories (local installation only).
Feature | Direct Remote (Pro) | Local Proxy (Free/Pro) | Full Local |
Claude Plan | Pro only | Free & Pro | Free & Pro |
Setup Time | 2 minutes | 5 minutes | 15-20 minutes |
Privacy | Remote storage | Remote storage | Complete privacy |
Customization | None | Middleware only | Full control |
Maintenance | Zero | Minimal | Manual updates |
Internet Required | Yes | Yes | No |
Code Required | No | 5 lines | Full codebase |
Cost | Pro subscription | Free | Free |
Check the configuration file path is correct
Ensure the command path points to your project directory (for local/proxy setup)
Verify the remote URL is correct (for direct remote setup)
Restart Claude Desktop completely
Check Claude Desktop logs for errors
If the remote server isn't responding:
Check your internet connection
Verify the URL: https://boiling-aqua-trout.fastmcp.app/mcp
Try removing and re-adding the configuration
Contact me via GitHub issues if the problem persists
If the proxy isn't working:
Test the proxy server independently: uv run main.py
Check if the remote URL is accessible
Verify your FastMCP installation: uv add fastmcp
Check Claude Desktop configuration paths
If you encounter database errors:
# Delete the database to reset
rm expense.db
# Restart the server to recreate the database
uv run main.py# Reinstall dependencies
uv syncYou can add custom logic to the proxy server:
from fastmcp import FastMCP
mcp = FastMCP.as_proxy(
"https://boiling-aqua-trout.fastmcp.app/mcp",
name="expense tracker remote proxy server"
)
# Add custom logging
@mcp.tool()
def log_expense_activity():
"""Log all expense activities"""
# Your custom logging logic here
pass
if __name__ == "__main__":
mcp.run()To modify the server:
Edit main.py
Test changes: uv run main.py
Restart Claude Desktop to load changes
Want to deploy your own version on FastMCP Cloud?
Sign up at FastMCP Cloud
Follow their deployment instructions
Update the URL in your Claude Desktop configuration or proxy code
Share your server URL with others!
Contributions are welcome! Feel free to submit issues or pull requests.
Add budget tracking and alerts
Support for multiple currencies
Recurring expense templates
Export to CSV/Excel
Data visualization and charts
Multi-user support with authentication
Authentication for remote server access
For issues related to:
This Project: GitHub Issues
MCP Protocol: MCP Documentation
FastMCP: FastMCP GitHub
Claude Desktop: Anthropic Support
Built with:
FastMCP - Framework for building MCP servers
Anthropic Claude - AI assistant platform
Model Context Protocol - Standard for AI-application integration
⭐ If you find this project helpful, please consider giving it a star on GitHub!
📧 Questions? Open an issue or reach out on LinkedIn
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| amount | Yes | ||
| category | Yes | ||
| subcategory | No | ||
| note | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete expenses based on any column criteria. like id,date,category,subcategory,amount,note,start_date,end_date
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| date | No | ||
| category | No | ||
| subcategory | No | ||
| amount | No | ||
| note | No | ||
| start_date | No | ||
| end_date | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a deletion operation but doesn't disclose critical behavioral traits: whether deletions are permanent or reversible, if there are confirmation prompts, what permissions are required, or what happens when multiple criteria match multiple records. The description is insufficient for a destructive operation 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?
Two sentences with no wasted words, but the second sentence is poorly formatted ('like' instead of 'e.g.' or 'such as') and reads as a continuation rather than proper structure. The information is front-loaded but could be more professionally presented.
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?
This is a destructive mutation tool with 8 parameters, 0% schema description coverage, no annotations, but has an output schema. The description fails to address critical context: deletion permanence, criteria logic, error conditions, or relationship to sibling tools. For a tool with this complexity and risk profile, the description is inadequate.
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 lists parameter names but doesn't explain their semantics: what format dates should use, whether 'amount' is exact match or range, how criteria combine (AND/OR), or what happens when no criteria are specified. The list adds minimal value beyond the schema's property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete expenses based on any column criteria' which provides a clear verb ('Delete') and resource ('expenses'), but it doesn't differentiate from sibling tools like 'update' which also modifies expenses. The purpose is understandable but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'update' or 'list_expenses'. The description mentions column criteria but doesn't explain prerequisites, constraints, or when this deletion is appropriate versus other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list all expenses within an inclusive date range
| Name | Required | Description | Default |
|---|---|---|---|
| start_date | Yes | ||
| end_date | 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 it's a list operation (implying read-only) and specifies date-range filtering, but doesn't mention pagination, sorting, authentication requirements, rate limits, error conditions, or what the return format looks like. For a list tool with zero annotation coverage, this leaves significant behavioral gaps.
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 wasted words. It's front-loaded with the core action ('list all expenses') followed by the key constraint ('within an inclusive date range'). Every word serves a purpose.
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 no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what an 'expense' object contains, how results are structured, whether there are limits on date ranges, or how to handle large result sets. For a list tool with two required parameters, more context is needed for effective 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?
Schema description coverage is 0% (parameters have only titles), so the description must compensate. It mentions 'inclusive date range' which implies the two parameters are date boundaries, but doesn't specify date format (ISO, timestamp, etc.), timezone handling, or whether dates are inclusive/exclusive. The description adds minimal semantic context beyond what's inferable from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource 'expenses', specifying the scope as 'within an inclusive date range'. It distinguishes from siblings like 'add_expense' (create) and 'update' (modify), but doesn't explicitly differentiate from 'summarize' which might also involve expense data. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'summarize' (which might provide aggregated data) or other siblings. It doesn't mention prerequisites, exclusions, or typical use cases. The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| start_date | Yes | ||
| end_date | Yes | ||
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an expense.Only provided fields will be updated.
| Name | Required | Description | Default |
|---|---|---|---|
| cid | Yes | ||
| date | No | ||
| amount | No | ||
| category | No | ||
| subcategory | No | ||
| note | No |
| Name | Required | Description |
|---|---|---|
| result | 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. While it mentions 'Only provided fields will be updated' (partial update behavior), it doesn't address important aspects like required permissions, whether updates are reversible, error conditions, or what happens when invalid data is provided. For a mutation tool with zero annotation coverage, this is insufficient.
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 - just two sentences that communicate the core functionality and a key behavioral aspect. Every word earns its place with zero redundancy or 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 this is a mutation tool with no annotations, 6 parameters (only 1 documented via description), but with an output schema present, the description is minimally adequate. The presence of an output schema means return values are documented elsewhere, but the description should do more to explain the mutation's behavior and parameter meanings.
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 some value by explaining the partial update behavior ('Only provided fields will be updated'), which helps interpret the null-able parameters in the schema. However, with 0% schema description coverage and 6 parameters, it doesn't explain what 'cid', 'date', 'amount', 'category', 'subcategory', or 'note' represent or their expected formats.
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 ('Update') and resource ('an expense'), making the purpose immediately understandable. However, it doesn't differentiate from the 'delete' sibling tool or explain what distinguishes this update operation from other potential expense modifications.
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 'add_expense' or 'delete'. There's no mention of prerequisites, constraints, or appropriate contexts for expense updates versus other operations.
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.
add_expensedeletelist_expensessummarizeupdateScored across 5 tools
Most tools have distinct purposes: add_expense, list_expenses, and update are clearly differentiated. However, 'summarize' lacks a description, which could cause confusion about its exact function relative to list_expenses, potentially leading to misselection if it overlaps in providing expense overviews.
The naming is mixed: add_expense, list_expenses, and summarize follow a verb_noun pattern, but 'delete' and 'update' are standalone verbs without nouns, breaking consistency. This deviation makes the set less predictable, though the names are still readable overall.
With 5 tools, the count is well-scoped for an expense tracker server, covering core operations like adding, listing, updating, deleting, and summarizing expenses. Each tool earns its place without feeling excessive or insufficient for the domain.
The toolset provides good CRUD coverage with add, list, update, and delete, along with a summarize function for analytics. A minor gap exists in the lack of descriptions for add_expense and summarize, which could hinder agent understanding, but core lifecycle operations are present and workable.
Log, query, and edit expenses, budgets, and accounts in Manilo from any MCP-compatible AI assistant.
Log, query, and edit expenses, budgets, and accounts in Manilo (formerly Ledgy) from any MCP-compatible AI assistant.
Personal finance tracker — log transactions, view summaries, and browse a dashboard
Log, query, and edit expenses, budgets, and accounts in Ledgy from any MCP-compatible AI assistant.
