Based on the server schema, this server only supports basic arithmetic operations: adding and multiplying two numbers. It does not expose any expense-tracking tools described in the README.
add: Takes two numbers (a and b) and returns their sum.
multiply: Takes two numbers (a and b) and returns their product.
No expense management tools (e.g., add_expense, list_expenses) are currently available.
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 Add a $45.50 expense for groceries and categorize it as food"
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 expenses with SQLite persistence.
Python 3.13 or higher
Node.js (for MCP Inspector)
uv (Python package manager)
Create a virtual environment:
python -m venv venvActivate the virtual environment:
.\venv\Scripts\Activate.ps1Install uv:
pip install uvInitialize the project:
uv init .Install dependencies:
uv add fastmcp --activeRelated MCP server: Expense Tracker MCP
To run the MCP server:
uv run main.pyThe server will automatically create a SQLite database (expenses.db) in the project root on first run.
To test the server using the MCP Inspector:
npx @modelcontextprotocol/inspector uv run main.pyThis will start the MCP Inspector web interface at http://127.0.0.1:6274.
The MCP server provides the following resources:
expense://categoriesReturns the predefined expense categories and their sub-categories.
Categories available:
Food: Groceries, Restaurant, Coffee, Vegetables, Snacks
Health: Pharmacy, Doctor, Fitness, Insurance
Entertainment: Streaming, Movies, Games, Events
Transport: Metro, Auto, Taxi, Fuel, Bus
Shopping: Clothing, Electronics, Home, Gifts
Utilities: Electricity, Internet, Water, Gas, Phone
This resource can be used to get the valid categories and sub-categories for expense tracking.
The MCP server provides the following tools for expense management:
add_expenseAdd a new expense record to the database.
Parameters:
amount (float): The amount spent
category (str): The expense category (e.g., "Food", "Transport")
date (str, optional): The expense date as YYYY-MM-DD. Defaults to today
sub_category (str, optional): An optional sub-category (e.g., "Groceries")
note (str, optional): An optional free-text note
Returns: The newly created expense record with its assigned ID
list_expensesList expense records with optional filtering.
Parameters:
start_date (str, optional): Only include expenses on or after this date (YYYY-MM-DD)
end_date (str, optional): Only include expenses on or before this date (YYYY-MM-DD)
category (str, optional): Only include expenses matching this category exactly
sub_category (str, optional): Only include expenses matching this sub-category exactly
limit (int, optional): Maximum number of records to return, most recent first
Returns: A list of matching expense records
edit_expenseEdit an existing expense record. Only provided fields are updated.
Parameters:
expense_id (int): The ID of the expense to edit
date (str, optional): New date as YYYY-MM-DD
amount (float, optional): New amount
category (str, optional): New category
sub_category (str, optional): New sub-category
note (str, optional): New note
Returns: The updated expense record
delete_expenseDelete an expense record by ID.
Parameters:
expense_id (int): The ID of the expense to delete
Returns: A confirmation dict with the deleted ID
summarize_expensesSummarize expenses with totals, optionally filtered and grouped.
Parameters:
start_date (str, optional): Only include expenses on or after this date (YYYY-MM-DD)
end_date (str, optional): Only include expenses on or before this date (YYYY-MM-DD)
category (str, optional): Only include expenses matching this category exactly
group_by (str): How to group the breakdown: "category", "sub_category", or "date". Defaults to "category"
Returns: A dict with overall total, count of matching expenses, and a breakdown list grouped by the requested field
expense-tracker-mcp/
├── main.py # Entry point for the MCP server
├── src/
│ └── expense_tracker_mcp/
│ ├── __init__.py
│ ├── server.py # MCP server implementation with expense tools
│ └── db.py # SQLite database persistence layer
├── pyproject.toml # Project configuration
├── expenses.db # SQLite database (auto-created, gitignored)
└── README.md # This fileFull expense tracking via MCP protocol
SQLite database for persistent storage
Add, list, edit, and delete expenses
Filter expenses by date, category, and sub-category
Summarize expenses with customizable groupings
Predefined expense categories and sub-categories
FastMCP integration for easy server setup
Compatible with MCP Inspector for testing
Expenses are stored in a SQLite database (expenses.db) with the following schema:
id: Primary key (auto-increment)
date: Expense date (YYYY-MM-DD format)
amount: Amount spent
category: Expense category
sub_category: Optional sub-category
note: Optional free-text note
The database is automatically created on first run and is excluded from version control via .gitignore.
MIT
Add two numbers together.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | The first number. | |
| b | Yes | The second number. |
| 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 the burden of behavioral disclosure. 'Add two numbers together' clearly implies a pure, deterministic, side-effect-free arithmetic operation. It does not mention potential precision or rounding behavior, but the openly simple scope makes this a minor omission.
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 six words long, front-loaded with the action verb, and contains zero filler. Every word earns its place.
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 two-parameter arithmetic tool, the description combined with full parameter schemas and an output schema is complete. The agent has everything needed to invoke add correctly and infer what the tool will do.
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 describes both parameters ('The first number' and 'The second number'), so schema coverage is 100%. The description adds no additional parameter-level meaning, so the baseline score 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 operation ('Add') and the resource ('two numbers'), making it immediately obvious what the tool does. It also inherently distinguishes itself from the sibling tool 'multiply' by describing addition rather than multiplication.
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 that the tool should be used when the desired operation is addition, but it does not explicitly mention when not to use it or name the sibling 'multiply'. For a simple two-tool arithmetic context this is sufficient, but there is no explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multiply two numbers together.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | The first number. | |
| b | Yes | The second number. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must stand alone. It describes the basic behavior but does not disclose any edge cases or result details. For such a simple pure operation this is minimally sufficient, but it is not rich.
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 fluff. It is perfectly sized for the tool's 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?
With simple required parameters, full schema coverage, and an output schema present, the description is enough to safely invoke the tool. Some additional edge-case context would be needed for a very complex tool, but it isn't necessary here.
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 describes both 'a' and 'b' with 100% coverage, so the tool description correctly matches the schema. The description itself adds no meaning 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 states the operation: 'Multiply two numbers together.' This is a specific verb and resource, and the operation is distinct from the sibling tool 'add' even though it does not explicitly mention it.
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 explicit when-to-use guidance or alternative comparison is provided. However, the implied usage is straightforward: an agent would invoke this when a product of two numbers is required.
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.
v0.1.0addmultiplyScored across 2 tools
Add and multiply are mathematically distinct operations with no behavioral overlap. An agent would never confuse which tool to call for a given arithmetic operation.
Both tools use a simple, consistent single-verb naming pattern in lowercase. This is predictable and easy to remember.
Two tools can be appropriate for a narrow utility, but for an 'Expense Tracker MCP' this count is far too small. The tools do not align with the server's stated purpose of expense tracking at all.
The expense tracking domain requires operations like adding expenses, listing entries, editing, and deleting. The provided add and multiply tools cover none of this domain, leaving the server severely incomplete.
Log, query, and edit expenses, budgets, and accounts in Manilo from any MCP-compatible AI assistant.
Paid remote MCP for context budgets, progressive loading, schema slimming, and readiness.
Hosted MCP server for Mini Accountant: invoices, expenses, customers, analytics, tax estimates.
Paid remote MCP for context-budget routing, schema cost estimates, usage audits, and readiness.
