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., "@Finance Tracking MCP Add a $45 fuel expense to transportation"
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 small MCP server for tracking personal expenses, built with FastMCP and SQLAlchemy on top of SQLite.
Tool | Description |
| Add a new expense (title, amount, category, optional date and note). Defaults to today's date. |
| Update an existing expense by ID — only the fields you pass are changed. |
| Totals and a per-category breakdown, optionally filtered by category and/or month ( |
Related MCP server: Expense Tracker MCP Server
URI | Description |
| The category list from |
Python 3.12+
uv run main.pyThe server creates expenses.db next to main.py on first run. That file is gitignored, so your data stays local.
Add the server to your MCP client config, for example:
{
"mcpServers": {
"finance-tracking": {
"command": "uv",
"args": ["run", "--directory", "/path/to/finance-tracking-mcp", "main.py"]
}
}
}main.py # MCP server: tools, resource, and SQLAlchemy models
categories.json # Category list exposed via the expense://categories resource
pyproject.toml # Project metadata and dependenciesAdd a new expense entry to the database.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ISO date YYYY-MM-DD (defaults to today) | |
| note | No | Optional extra description | |
| title | Yes | Short name, e.g. 'Lunch at Subway' | |
| amount | Yes | Amount spent (positive number) | |
| category | Yes | e.g. 'Food', 'Transport', 'Shopping' |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must disclose behavioral traits. It only says 'Add a new expense entry' without mentioning side effects, authentication needs, return values, or error conditions. This is minimal disclosure 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, direct sentence with no unnecessary words. It conveys the essential purpose 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?
The tool is simple and the schema covers parameters, but with no annotations and no mention of output or behavioral nuances, the description is only minimally complete. It covers the basic action but leaves usage context and side effects unclear.
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 already provides detailed descriptions for all five parameters with 100% coverage. The tool description adds no extra parameter meaning, so the baseline of 3 is appropriate.
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 'Add' and the resource 'expense entry to the database', which precisely conveys the tool's function. It distinguishes itself from siblings like expense_summary (reading) and edit_expense (modifying) by targeting new records.
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 that it is only for new entries, how it differs from edit_expense, or any context for when to prefer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit an existing expense by ID. Only pass the fields you want to change.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | New date YYYY-MM-DD (optional) | |
| note | No | New note (optional) | |
| title | No | New title (optional) | |
| amount | No | New amount (optional) | |
| category | No | New category (optional) | |
| expense_id | Yes | ID of the expense to update |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral details are provided beyond the fact that it edits an expense. There is no mention of side effects, such as whether it overwrites existing fields or if there are any constraints or error conditions. Since there are no annotations, the description carries the burden but fails to disclose these 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 extremely concise with no redundant information. It conveys the core purpose and the partial-update behavior in two short sentences, 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?
For a simple edit operation, the description is adequate. It clearly states the essential behavior and the schema covers parameter details. It does not mention return values, but given the simplicity, this omission is acceptable.
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 provides descriptions for each parameter (e.g., 'New date', 'New note'), covering the meaning. The description adds the semantic nuance that omitted fields remain unchanged, which is a helpful clarification but does not significantly augment 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 states the tool edits an existing expense by ID, which distinguishes it from adding or summarizing. It does not explicitly mention which fields can be edited, but that is covered in the schema.
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 phrase 'Only pass the fields you want to change' implies partial updates, but there is no explicit guidance on when to use this tool versus adding a new expense or summarizing expenses. The usage context is implied, not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a spending summary, optionally filtered by category and/or month.
| Name | Required | Description | Default |
|---|---|---|---|
| month | No | Filter by month in YYYY-MM format, e.g. '2025-03' (optional) | |
| category | No | Filter by category name, e.g. 'Food' (optional) |
| 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 the burden. It implies a read operation and aggregation, but does not explicitly state that it does not modify data, nor does it mention any other behavioral aspects like pagination or data scope. The description is minimal and lacks depth for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the action and optional filters. It is front-loaded and contains no filler or redundant information, making it highly efficient.
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 with two optional parameters and an output schema. The description adequately communicates the core functionality and filter options. While it does not elaborate on what the summary includes, the existence of an output schema reduces that need. It is complete enough for a straightforward read tool.
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% as both parameters have detailed descriptions in the schema. The description only restates that filters are optional, adding no new meaning beyond what the schema already provides. This aligns with the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get a spending summary' with optional filters. This distinguishes it from sibling tools like add_expense and edit_expense, which are mutations. The verb 'Get' and resource 'spending summary' are 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 implies read-only usage (get vs. add/edit), but does not explicitly state when to use it over siblings or mention any exclusions. It provides clear context for a summary retrieval but lacks explicit guidance on alternatives or prerequisites.
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.
v0.1.0add_expenseedit_expenseexpense_summaryEach tool serves a clearly distinct purpose: summarizing expenses, adding new ones, and editing existing ones. There is no overlap or ambiguity in their functions.
Two tools follow a verb_noun pattern (add_expense, edit_expense), while expense_summary deviates slightly as a noun-first name. This minor inconsistency does not hinder readability.
With only 3 tools, the server is well-scoped for a focused expense tracking purpose. Each tool earns its place with no redundancy or excess.
The server covers add, edit, and summary, but lacks a delete operation and a way to retrieve individual expense details. This represents a notable gap in lifecycle coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Personal finance tracker — log transactions, view summaries, and browse a dashboard
Personal finance ledger for AI agents — query spending, track bills, forecast cash flow.
Track expenses, budgets, balances, transfers, and multi-currency reports with OAuth-secured tools.
Manage shared household finances for two people - expenses, budgets, savings, and settlements.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Siddharth202002/finance-tracking-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
