This server enables AI assistants to manage personal finances by tracking expenses and income in a local SQLite database.
Add Expense: Add a new expense with amount, category, and optional description and date (defaults to current date).
Get Expenses: List and filter expenses by category, month, or year.
Get Summary: Generate a monthly summary of spending and income, grouped by category (month and year required).
Delete Expense: Delete an expense by its unique ID.
Add Income: Add new income records (e.g., Salary, Investments).
Get Income: List and filter income records.
Delete Income: Delete an income record by its unique ID.
Access Categories: Get predefined JSON mappings of categories and sub-categories for both income and expenses.
Click on "Install 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 Add an expense of $15.50 for lunch under Food category today."
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 built with Python and FastMCP that allows LLM assistants (like Claude Desktop) to track, query, summarize, and delete personal expenses using a local SQLite database.
This project provides an intelligent financial tracker backend accessible via MCP tools. With this MCP server, an AI assistant can manage your personal expenses directly through conversational prompts.
config://categories: Provides a predefined JSON mapping of categories and sub-categories for both income and expenses.
add_expense: Add a new expense with amount, category, optional description, and optional date.
get_expenses: List and filter expenses by category, month, or year.
delete_expense: Remove an expense record by its unique ID.
add_income: Add a new income record (e.g., Salary, Investments).
get_incomes: List and filter income records.
delete_income: Remove an income record by its unique ID.
get_summary: Generate a monthly summary grouped by spending and income categories.
Related MCP server: ExpenseTracker MCP Server
uv (Fast Python package installer and runner)
Claude Desktop (or any MCP-compliant client)
Navigate to the project root directory:
cd C:\Users\arjun\Desktop\papi\expense-tracker-mcpInstall the required dependencies using uv:
uv pip install fastmcpmain.py)The application defines an MCP server using FastMCP and initializes an SQLite database (expenses.db) automatically upon execution:
import datetime
from fastmcp import FastMCP
import os
import sqlite3
DB_PATH = os.path.join(os.path.dirname(__file__), "expenses.db")
mcp = FastMCP(name="Expense Tracker")
# Database Initialization
def init_db():
with sqlite3.connect(DB_PATH) as c:
c.execute('''
CREATE TABLE IF NOT EXISTS expenses (
id INTEGER PRIMARY KEY AUTOINCREMENT,
amount REAL NOT NULL,
category TEXT NOT NULL,
description TEXT,
date DATE NOT NULL DEFAULT CURRENT_DATE
)
''')
init_db()You can run the server locally to ensure there are no syntax errors:
uv run python main.pyIf using standard Claude Desktop:
uv run fastmcp install claude-desktop main.pyIf using the Microsoft Store version of Claude Desktop, open your claude_desktop_config.json:
Path: %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json
Add the server entry under mcpServers:
{
"mcpServers": {
"expense-tracker": {
"command": "uv",
"args": [
"run",
"python",
"C:\\Users\\arjun\\Desktop\\papi\\expense-tracker-mcp\\main.py"
]
}
}
}Close and fully quit Claude Desktop.
Relaunch Claude Desktop.
Look for the 🔌 icon to verify that the Expense Tracker tools are active.
Once configured in Claude Desktop, you can interact with your tracker using natural prompts:
"Add an expense of $15.50 for lunch under Food category today."
"Show all my Food expenses for this month."
"Give me a spending summary for August 2026."
"Delete expense ID 3."
Add a new expense to the tracker.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Optional date of the expense in YYYY-MM-DD format. Defaults to current date. | |
| amount | Yes | The amount of the expense. | |
| category | Yes | The category of the expense (e.g., Food, Transport, Utilities). | |
| description | No | Optional description of the expense. |
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 only says 'Add a new expense' and does not mention that the operation is permanent, what the response will be, or any potential side effects. For a mutation tool, this is a significant gap.
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 redundant words or filler. It is appropriately sized for a simple tool and every word contributes to the meaning.
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?
The tool is simple and the schema provides complete parameter details, but with no annotations or output schema, the description should ideally note what happens on success (e.g., a confirmation) or any lasting effects. The current description is minimal but adequate for a basic create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents all parameters with descriptions, defaults, and formats (100% coverage). The description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
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 'Add a new expense to the tracker' clearly identifies the action (add), the resource (expense), and the context (tracker). It is distinct from sibling tools that get, summarize, or delete expenses.
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 usage context is provided. The description does not mention when to use this tool, prerequisites, or when not to use it compared to alternatives like delete_expense. It simply states the action without any conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an expense by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| expense_id | Yes | The ID of the expense to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to fall back on, and the description only states the action without disclosing behavioral traits such as permanence of deletion, return values, or error behavior. This is a minimal description for a mutating operation.
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, focused sentence that directly states the operation and the key parameter. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description is sufficient to convey the core operation. However, it omits potential details about outcomes or side effects, which are not covered by annotations or schema. For a simple delete, this is marginally adequate.
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 schema already describes expense_id fully ('The ID of the expense to delete'), and the description's 'by its ID' adds no additional meaning. With 100% schema coverage, the baseline of 3 applies; no extra semantics are provided.
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 uses the specific verb 'Delete' with the object 'expense' and identifies the parameter 'by its ID,' clearly distinguishing this from sibling tools like add_expense, get_expenses, and get_summary. It says exactly what the tool does and on what resource.
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 offers no explicit guidance on when to use this tool rather than alternatives, nor any prerequisites or exclusions. The only hint is the verb 'Delete,' but no context about permissions, irreversibility, or when to choose this over sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of expenses.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Optional year. | |
| month | No | Optional month (1-12). | |
| category | No | Optional category to filter by. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It merely states 'Get a list of expenses' without explaining that filtering is optional, whether the result is paginated, or any access requirements. The behavior is minimally transparent but lacks useful 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?
The description is a single sentence that effectively communicates the core function. It contains no filler, is immediately clear, and is appropriately sized for a simple read tool.
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 and full schema coverage, the description is mostly adequate. However, it lacks any mention of optional filters or how the result relates to get_summary, leaving some contextual gaps. It does not need to explain return values since no output schema exists, but more behavioral detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning each parameter (year, month, category) already has a description. The tool description adds no additional parameter semantics. Baseline of 3 is appropriate given the schema fully documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a list of expenses' uses a specific verb and resource, clearly indicating the tool's purpose. It is distinguishable from siblings add_expense, delete_expense, and get_summary, as it focuses on listing expenses rather than modifying or summarizing them.
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 does not mention scenarios where get_expenses is preferred over get_summary, nor does it note any prerequisites or limitations. There is no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a summary of expenses by category for a specific month.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | The year. | |
| month | Yes | The month (1-12). |
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 core behavior (summarizing expenses by category for a month) but does not disclose details like whether the summary includes totals, counts, or only categories with expenses, nor does it mention what happens if no expenses exist.
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, front-loaded sentence that immediately conveys the tool's purpose and key qualifier (by category, for a specific month). It contains no fluff or redundant information.
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 (two required parameters, no output schema, no annotations), the description adequately conveys the tool's function and required inputs. It could be slightly more complete by specifying the return format or edge cases, but the core selection and invocation information is present.
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 100% with each parameter described in the schema. The description adds context by noting the summary is for a 'specific month', linking both year and month parameters to the tool's purpose, but it does not provide extra syntax or format details beyond the schema.
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 specifies the action (Get), the resource (summary of expenses), and the exact scope (by category for a specific month). It distinguishes this from sibling tools like get_expenses, which likely returns detailed expense records rather than an aggregated summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for obtaining an aggregated view by category for a month, but it does not explicitly mention when to use this over get_expenses or list any exclusions. Sibling tool names are present but not referenced in the description, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: adding, listing, summarizing, and deleting expenses. There is no overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern (add_expense, get_expenses, get_summary, delete_expense). The naming is uniform and predictable.
Four tools is a well-scoped count for an expense tracker. Each tool serves a core function without unnecessary bloat.
The set covers create, read, and delete operations, but lacks an update operation for expenses. This is a minor gap that can be worked around by deleting and re-adding.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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, bank account, and shared memory connector for Claude, ChatGPT, Gemini Spark & more
Log, query, and edit expenses, budgets, and accounts in Ledgy from any MCP-compatible AI assistant.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/arjunnavadiya8/expense-tracker-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
