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 Manager MCP Server How much did I spend on food 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.
An MCP server for managing personal expenses using Python, FastMCP, and SQLite.
Connect it to Claude Desktop and manage your expenses using natural language.
Add, update, and delete expenses
Search expenses
List expenses by date range
Summarize spending by category
Store data locally using SQLite
Expose expense categories through an MCP resource
Related MCP server: Expense Tracker MCP Server
Python 3.11+
FastMCP
Model Context Protocol (MCP)
SQLite
uv
git clone https://github.com/sonali1103/expense-manager-mcp-server.git
cd expense-manager-mcp-server
uv syncFrom the project directory, run:
pwdCopy the path returned. You'll need it in the Claude configuration.
In Claude Desktop:
Settings → Developer → Edit Config
This opens claude_desktop_config.json.
On macOS, the file is located at:
~/Library/Application Support/Claude/claude_desktop_config.jsonAdd the following inside mcpServers:
{
"mcpServers": {
"expense-manager": {
"command": "uv",
"args": [
"--directory",
"/YOUR/PATH/expense-manager-mcp-server",
"run",
"main.py"
]
}
}
}Replace:
/YOUR/PATH/expense-manager-mcp-serverwith the path you copied from pwd.
Completely quit and reopen Claude Desktop.
Then click the Connectors icon near the chat box and verify that expense-manager is connected. Claude Desktop will show the MCP tools provided by the server.
Once connected, ask Claude:
"Add a $45 grocery expense for today."
"Show me my expenses for this month."
"How much did I spend on food this month?"
"Find my travel expenses."
"Delete expense 12."
Tool | Description |
| Add an expense |
| List expenses by date range |
| Summarize spending |
| Update an expense |
| Delete an expense |
| Search expenses |
Expenses are stored locally in:
expenses.dbThe database and expenses table are created automatically when the server starts.
expense-manager-mcp-server/
├── main.py
├── categories.json
├── pyproject.toml
├── uv.lock
└── .gitignoreThis project demonstrates how Model Context Protocol connects an AI assistant to real application functionality and data through standardized tools.
Add a new expense entry.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| note | No | ||
| amount | Yes | ||
| category | Yes | ||
| subcategory | 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 the full burden of behavioral disclosure. It only states that a new expense entry is added, with no mention of duplicate handling, ID generation, validation rules, or response behavior. For a write operation, this is sparse.
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?
One sentence with no filler, and the action is front-loaded. It does not waste words, though the brevity comes at the cost of substance.
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?
An output schema exists, so return values need not be explained, but the missing parameter semantics and zero annotations leave critical gaps. An agent cannot infer required value formats or categories, making the description incomplete for a five-parameter create 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 0%, and the description does not compensate. It offers no explanation of date format, amount constraints, allowed categories, or how note and subcategory defaults behave. With five parameters, the description adds virtually no meaning beyond the input 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?
States a specific verb ('Add') and resource ('expense entry'), and the verb alone separates it from siblings such as list_expenses, update_expense, delete_expense, and search_expenses. There is no ambiguity about which expense operation this is.
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?
Provides no context about when to use this tool versus alternatives like update_expense or search_expenses. There are no prerequisites, conditions, or exclusions, so the when-to-use guidance is only tautologically implied by the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an expense entry by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. 'Delete' clearly indicates a destructive action, but the description does not mention irreversibility, authorization requirements, side effects, or any safeguards, which is a meaningful gap for a mutation tool.
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 with no wasted words. Every word contributes to understanding what the tool does and what input it expects.
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 one-parameter delete action, the description is minimally functional and an output schema exists. However, given the absence of annotations and the destructive nature of the tool, it would be more complete with a note about permanence or a pointer to related tools for locating the ID.
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 clarify the parameter. It does specify that the 'id' is the identifier of the expense entry, adding semantic meaning to the plain integer schema. However, it provides no additional context such as where the ID comes from or how to obtain it.
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 a specific verb ('Delete'), a precise resource ('expense entry'), and the required selector ('by ID'). This clearly differentiates it from siblings such as update_expense, add_expense, and list_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?
The description implies the tool is used when an expense entry needs to be removed and an ID is available. However, it does not explicitly state when not to use it, nor does it reference alternative tools such as update_expense or search_expenses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List expenses within an inclusive date range.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | ||
| start_date | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the disclosure burden; 'List' implies read-only and 'inclusive date range' adds a boundary detail. However, it does not explicitly state side-effect safety, ordering, pagination, or failure behavior, though the output schema covers the return shape.
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?
A six-word sentence that is front-loaded and contains no 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 list tool with an output schema, this is adequate but not complete: it lacks date-format conventions, an explicit read-only/side-effect statement since no annotations exist, and a pointer to when search_expenses or summarize would be the better choice.
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%, and the description only says the range is inclusive; it does not specify date format, timezone, or deeper meaning beyond the parameter names. The names are self-explanatory, but the description does not substantially compensate for absent schema descriptions.
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?
States a specific verb ('List'), resource ('expenses'), and an explicit date-range scope with inclusive bounds. It clearly describes the operation, but does not differentiate it from the sibling search_expenses, which may overlap in behavior.
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 about when to choose this tool over search_expenses or summarize. The description only states what it does, leaving alternative selection to agent inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search expenses by category, subcategory, or note.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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, but it only states the search fields. It does not clarify matching semantics (exact vs. substring), whether results are paginated via limit, or what the response contains. The verb 'search' weakly implies a read-only operation, but this is not explicit.
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 with no redundant wording or filler. It is concise and front-loads the core searchable fields, though it sacrifices some behavioral and usage detail for brevity.
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 search tool with an output schema, the description covers the essential query semantics but leaves out usage differentiation, matching behavior, and limit behavior. It is minimally viable but not fully complete for an agent that must choose between several expense-related tools.
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%, but the description does add meaning to 'query' by specifying that it matches category, subcategory, or note. The 'limit' parameter receives no semantic explanation beyond its integer type and default value, so the description only partially compensates for the schema gap.
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 names a specific action ('search') and resource ('expenses'), and identifies the searchable fields: category, subcategory, or note. It is not a tautology and gives enough detail to distinguish search expenses from expense mutation tools, though it does not explicitly contrast with list_expenses or summarize.
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 when to use the tool: when the agent needs to find expenses by category, subcategory, or note. However, it provides no explicit guidance about when to prefer search_expenses over list_expenses or summarize, nor any exclusions or fallback conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize expenses by category within an inclusive date range.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | ||
| end_date | Yes | ||
| start_date | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently discloses the inclusive date-range behavior and the category grouping, but it does not explicitly state that the operation is read-only or describe edge cases such as expenses without categories or with empty ranges. Some behavioral context is provided, though not complete.
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 with no wasted words. The key scoping qualifier 'inclusive date range' is integrated efficiently, making the definition easy to parse and remember.
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 output schema exists, the lack of return-value detail is acceptable. However, because there are no annotations and the schema has low parameter coverage, the description should clarify category semantics and date format to be fully self-sufficient. It is adequate but leaves an agent to infer some important call details.
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 adds 'inclusive' for the date bounds and suggests category plays a role in the summary, but it never specifies the expected date format or what a null/omitted category means. The ambiguity between 'group by category' and 'filter to a specific category' leaves critical parameter semantics unclear.
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 a specific verb ('summarize'), a resource ('expenses'), a grouping dimension ('by category'), and date-range semantics ('inclusive'). This distinguishes it from the sibling mutation and raw-list tools, making the tool's purpose 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 verb 'summarize' implies aggregation, so an agent can infer when to choose this over list_expenses or search_expenses, but the description does not explicitly state when to use it or when not to use alternatives. The usage context is implied rather than stated, leaving room for misselection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update only the provided fields of an existing expense.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| date | No | ||
| note | No | ||
| amount | No | ||
| category | No | ||
| subcategory | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It usefully reveals the patach semantics: omitted fields remain unchanged. However, it does not address what happens with null values, invalid ids, idempotency, or side effects. The main behavioral trait is disclosed, but richer context is missing.
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?
One sentence, no wasted words, and the core behavior is front-loaded. The description is appropriately sized for the tool's simple patch semantics.
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 description is minimally viable for an update tool: it states the operation, the resource, and the patach semantics, and the output schema handles return-value concerns. But with no annotations and no per-parameter descriptions, an agent still faces ambiguity around null vs omitted fields and how to handle non-existent expenses. It is adequate but noticeably incomplete.
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 adds the useful fact that only provided fields are updated, but it does not explain the six parameters individually, the role of the required id, or the distinction between omitting a field and explicitly passing null. The gap is significant for a 6-parameter patch tool.
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 a specific verb ('Update') with a clear resource ('an existing expense') and narrows scope to partial updates ('only the provided fields'). This distinguishes it from sibling tools like add_expense, delete_expense, list_expenses, and search_expenses, even though those alternatives are not named.
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 the tool is for modifying an existing expense rather than creating, deleting, or reading one, but it does not explicitly state when to prefer it over a sibling or give exclusions. The context is decipherable from the resource and operation, but the guidance is only implied, not explicit.
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.0add_expensedelete_expenselist_expensessearch_expensessummarizeupdate_expenseScored across 6 tools
Each tool targets a distinct action: create, list, summarize, update, delete, and search. There is minimal overlap because list_expenses is date-based while search_expenses is field-based, and summarize provides aggregation rather than raw entries.
Most tools follow a clear verb_noun pattern: add_expense, list_expenses, update_expense, delete_expense, search_expenses. The only minor deviation is 'summarize' lacking an explicit object, though it is still readable and clearly related to expenses.
Six tools is a well-scoped size for an expense manager. Each tool serves a distinct purpose without unnecessary bloat or missing core functionality.
The tool set covers the full expense lifecycle: add, list, search, summarize, update, and delete. There are no major dead ends; users can create, retrieve, modify, and remove expenses, with search and summary features for analysis.
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 tracker — log transactions, view summaries, and browse a dashboard
Personal finance by conversation: expenses, receipts, statement import, budgets, net worth.
