Skip to main content
Glama
Raghunandan2813

Expense Tracker MCP Server

by Raghunandan2813
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

💸 Expense Tracker MCP Server

A professional Model Context Protocol (MCP) server designed to help you track, analyze, and optimize your personal finances. This server provides tools to add expenses, list transactions, and generate detailed financial summaries with Indian Rupee (₹) support and strategic advice.

🚀 Features

  • Add Expenses: Easily log expenses with categories, dates, and notes.

  • Tabular Summaries: Professional reports in tabular format showing counts, totals, and percentages.

  • Financial Advice: Strategic solutions tailored to your spending habits (Needs vs. Wants).

  • Visual Graphs: Built-in support for Mermaid.js charts and Matplotlib PNG graphs for visual distribution.

  • INR Support: All financial values are formatted in Indian Rupees (₹).

Related MCP server: Trackor

🛠️ Installation

1. Clone the Repository

git clone https://github.com/your-username/expense-tracker.git
cd expense-tracker

2. Install Dependencies (Recommended: uv)

If you have uv installed, simply run:

uv sync

Alternatively, using standard pip:

python -m venv .venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate
pip install -r requirements.txt

🖥️ Usage

Running the Server

If using uv, you can run the server directly:

uv run main.py

Otherwise, use python:

python main.py

Claude Desktop Integration

To use this with Claude Desktop, add the following to your claude_desktop_config.json:

{
  "mcpServers": {
    "Expense Tracker": {
      "command": "uv",
      "args": ["--directory", "C:/path/to/expense-tracker", "run", "main.py"]
    }
  }
}

Note: Replace C:/path/to/ with the actual absolute path to your project directory.

📂 Project Structure

  • main.py: The core MCP server implementation.

  • expenses.db: SQLite database for persistent storage.

  • requirements.txt: List of Python dependencies.

  • pyproject.toml: Project configuration for tools like uv.

🧠 Smart Tools

  • add_expense: Add a new expense record.

  • list_expenses: Retrieve transactions within a date range.

  • summarize: Get a detailed financial report with graphs and advice.

  • categories: List all supported expense categories.

⚖️ License

MIT

Available Tools

3 tools
add_expenseD
ParametersJSON Schema
NameRequiredDescriptionDefault
dateYes
noteNo
amountYes
categoryYes
subcategoryNo

TDQS

D1/5.0
Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

list_expensesD
ParametersJSON Schema
NameRequiredDescriptionDefault
end_dateYes
start_dateYes

TDQS

D1/5.0
Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

summarizeA

Summarize expenses between two dates, providing a detailed analysis, financial advice, and a visualization graph.

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryNo
end_dateYes
start_dateYes

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It mentions that the tool provides 'analysis, financial advice, and a visualization graph,' which gives some sense of output behavior, but it does not explicitly disclose side effects, permissions, or limitations. The read-only nature is implied but not stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no fluff. It places the main verb and resource first, then adds the key outputs. Every word contributes to the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and no annotations, so the description must explain outputs and parameter behavior. It does mention the three output types (analysis, advice, graph) but lacks detail on formats or how the category filter works. While the core purpose is covered, several important aspects remain unclear.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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 only hints at the purpose of start_date and end_date via 'between two dates' but omits any details about date formats, inclusivity, or the 'category' parameter entirely. This leaves significant ambiguity for the optional parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the function with a specific verb ('Summarize'), resource ('expenses'), and scope ('between two dates'). It also distinguishes itself from siblings by mentioning unique outputs: 'detailed analysis, financial advice, and a visualization graph.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for analytical summarization rather than adding or listing expenses, but it does not explicitly state when to use it over alternatives or provide any exclusions. The context is clear but relies on inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updatesv0.1.0
    • First observedadd_expense
    • First observedlist_expenses
    • First observedsummarize
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.3/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: adding an expense, listing expenses, and summarizing/analyzing them. There is no overlap in their core functions, making it easy for an agent to choose the right tool.

Naming Consistency4/5

Most tools follow the verb_noun pattern (add_expense, list_expenses), but 'summarize' lacks an object, deviating from the pattern. There is also a minor singular/plural inconsistency between 'expense' and 'expenses'. Overall the convention is readable and predictable.

Tool Count4/5

With only three tools, the set is minimal but appropriate for a simple expense tracker. The count is not excessively thin (like 1-2) and stays within a reasonable scope, though one could imagine additional tools for management.

Completeness3/5

The server covers creating and reading expenses, plus a summary/analysis function, but lacks update and delete operations. For an expense tracker, the inability to modify or remove expenses is a notable gap that agents would have to work around.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Trackor

    At0mXploit
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables users to track and manage personal expenses through natural language, including adding entries, filtering by date/category, viewing statistics, and exporting data in JSON or CSV format.
    3
    -

  • Expense Tracker MCP

    Rawal1755
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables tracking of personal expenses with tools to add, list, update, delete, and summarize expenses by category.
    -

  • expense-tracker-mcp-server

    SINGH-HARSH1
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables users to manage personal finances using natural language, including tracking expenses, income, budgets, and generating financial summaries.
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Raghunandan2813/Mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server