Claude와 같은 AI 어시스턴트가 로컬 SQLite 데이터베이스를 사용하여 개인 지출을 관리(추가, 분류, 요약 및 예산 설정)할 수 있게 해주는 MCP(Model Context Protocol) 서버입니다.
이 서버는 Claude(또는 MCP 호환 클라이언트)가 지출을 추적하기 위해 호출할 수 있는 일련의 MCP 도구를 제공합니다. 모든 데이터는 로컬 SQLite 파일에 저장되며, 클라우드나 계정이 필요하지 않습니다.
Related MCP server: Expense Tracker MCP Server
카테고리, 금액, 날짜, 설명과 함께 지출 추가 및 관리
날짜 범위 또는 카테고리별로 지출 필터링 및 목록 조회
카테고리 또는 월별 지출 요약
카테고리별 예산 설정 및 잔액 확인
CSV로 지출 내역 내보내기
완전한 로컬 환경 — 데이터가 사용자 기기에만 저장됨
도구 | 설명 | 주요 매개변수 |
| 새로운 지출 기록 |
|
| 선택적 필터를 사용하여 지출 목록 조회 |
|
| 카테고리 또는 월별로 그룹화된 합계 |
|
| ID를 사용하여 기존 지출 수정 |
|
| ID를 사용하여 지출 삭제 |
|
| 카테고리별 월간 예산 한도 설정 |
|
| 예산 한도와 실제 지출 비교 |
|
| 지출 내역을 CSV 문자열로 내보내기 |
|
expense-tracker-mcp-server/
├── main.py # MCP server entry point (all tools)
├── expenses.db # SQLite database (auto-created on first run)
├── pyproject.toml # Project metadata and dependencies
├── .venv/ # Virtual environment (created by uv)
└── readme.mdPython 3.11 이상
uv (권장) 또는 pip
Claude Desktop (MCP 서버 연결용)
# Clone the repo
git clone https://github.com/your-username/expense-tracker-mcp-server.git
cd expense-tracker-mcp-server
# Initialize the project and install dependencies
uv init
uv add fastmcp이 명령은 프로젝트 디렉토리 내에 .venv 폴더를 자동으로 생성합니다.
fastmcp run main.py서버가 시작되고 stdio를 통해 MCP 연결을 대기합니다. SQLite 데이터베이스(expenses.db)는 처음 실행 시 자동으로 생성됩니다.
Claude Desktop 설정 파일에 다음 내용을 추가하세요:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"expense-tracker": {
"command": "uv",
"args": [
"--directory",
"C:\\Learning\\Expense-Tracker-MCP-Server",
"run",
"fastmcp",
"run",
"main.py"
]
}
}
}Claude Desktop을 완전히 종료(시스템 트레이 → 종료)한 후 다시 실행하세요. 도구 패널에서 지출 추적기 도구를 확인할 수 있습니다.
Claude에 연결되면 다음과 같이 말할 수 있습니다:
"오늘 Whole Foods에서 식료품비로 45달러 지출 추가해줘"
"이번 달 식비 지출 내역 모두 보여줘"
"지난달에 가장 많이 지출한 항목이 뭐야?"
"외식비로 월 300달러 예산을 설정해줘"
"엔터테인먼트 예산이 얼마나 남았어?"
"3월 지출 내역을 모두 CSV로 내보내줘"
# Run with MCP inspector for debugging
fastmcp dev inspector main.pyMIT
Add a new expense. Date format: YYYY-MM-DD (defaults to today).
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | ||
| category | Yes | ||
| description | No | ||
| date | No | ||
| currency | No | USD |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions date format and default behavior, but doesn't address important aspects like whether this is a write operation (implied but not stated), what permissions are needed, how errors are handled, or what the response contains.
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 just two sentences that both add value. The first sentence states the core purpose, and the second provides important implementation detail about date formatting. There's zero wasted text.
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 write operation with 5 parameters and no annotations, the description is minimal but covers the essential action. The existence of an output schema means the description doesn't need to explain return values, but it should provide more guidance about usage context and behavioral expectations for a mutation 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?
With 0% schema description coverage, the description adds minimal value beyond the schema. It only provides information about the 'date' parameter (format and default), leaving the other 4 parameters (amount, category, description, currency) without additional semantic context beyond what the schema provides.
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 action ('Add a new expense') and resource ('expense'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'update_expense' or explain how it differs from 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 like 'update_expense' or 'list_expenses'. It mentions date format but doesn't explain when this tool is appropriate versus other expense-related operations.
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 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Delete' implies a destructive mutation, the description doesn't specify whether this action is reversible, requires specific permissions, has side effects (e.g., on budget calculations), or returns confirmation details. For a destructive tool with zero annotation coverage, this is a significant gap in transparency.
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 zero wasted words, making it highly concise and front-loaded. Every word ('Delete an expense by ID') contributes essential information, achieving optimal efficiency for such a simple 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 complexity (a destructive mutation), lack of annotations, and presence of an output schema (which reduces the need to describe return values), the description is minimally adequate. It states the core action but misses critical context like behavioral traits, usage guidelines, and parameter details, making it incomplete for safe and effective use by an agent.
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 description coverage is 0%, but the description adds minimal semantic context by specifying that the 'id' parameter is used to identify the expense to delete. However, it doesn't explain what format the ID should be (e.g., integer, string) or where to find it, leaving the schema to carry most of the parameter documentation burden. With one parameter, the baseline is 4, but the lack of detail reduces this to 3.
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 action ('Delete') and target resource ('an expense by ID'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'update_expense' or 'list_expenses' beyond the basic verb, which prevents a perfect score.
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 like 'update_expense' or 'list_expenses'. It lacks context about prerequisites (e.g., whether the expense must exist), exclusions, or recommended workflows, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export expenses as a CSV string.
| Name | Required | Description | Default |
|---|---|---|---|
| start_date | No | ||
| end_date | No | ||
| category | No |
| 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 full burden of behavioral disclosure. It states the action ('Export') but doesn't clarify if this is a read-only operation, whether it requires specific permissions, or if it has side effects like generating files. The mention of 'CSV string' hints at output format but lacks details on rate limits, error handling, or data scope.
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, efficient sentence with zero wasted words. It's front-loaded with the core action and output, making it easy to parse quickly. Every word earns its place by conveying essential information without redundancy.
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 moderate complexity (3 parameters, no annotations) and the presence of an output schema, the description is minimally adequate. It specifies the output format ('CSV string'), which the output schema likely details further, but it doesn't address parameter meanings or behavioral traits, leaving gaps in contextual understanding.
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 description coverage is 0%, so the description must compensate for undocumented parameters. It mentions no parameters at all, failing to explain the meaning or usage of 'start_date', 'end_date', and 'category'. This leaves the agent with no semantic understanding beyond the schema's structural definition.
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 ('Export') and resource ('expenses') with the output format ('as a CSV string'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_expenses' or 'get_expense_summary', which might also retrieve expense data but in different formats or structures.
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 like 'list_expenses' or 'get_expense_summary'. It lacks context about scenarios where CSV export is preferred over other data retrieval methods, and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare budget limits vs actual spend. Month format: YYYY-MM (defaults to current month).
| Name | Required | Description | Default |
|---|---|---|---|
| month | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions the month parameter format and default, which is useful, but doesn't describe key behaviors such as what data is returned (e.g., comparison details, error handling), whether it's a read-only operation, or any performance considerations. For a tool with no annotation coverage, 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 highly concise and front-loaded, consisting of two clear sentences that directly state the tool's purpose and parameter details without any wasted words. Every sentence earns its place by providing essential information 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?
Given the tool's moderate complexity (one parameter, no annotations, but with an output schema), the description is minimally adequate. It covers the basic purpose and parameter semantics, but since there's an output schema, it doesn't need to explain return values. However, for a tool with no annotations, it could benefit from more behavioral context to be fully complete.
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 description adds meaningful context for the single parameter by specifying the month format ('YYYY-MM') and default behavior ('defaults to current month'), which goes beyond the input schema's minimal coverage (0% schema description coverage). Since there's only one parameter, this effectively compensates for the schema's lack of detail, though it doesn't fully explain all possible semantics.
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 purpose with a specific verb ('Compare') and resources ('budget limits vs actual spend'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_expense_summary' or 'list_expenses', which might also involve budget/spend analysis, so it doesn't reach the highest score.
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 usage by specifying the month parameter format and default, suggesting it's for checking budget status in a given month. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_expense_summary' or 'list_expenses', nor does it mention prerequisites or exclusions, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize total spending grouped by 'category' or 'month'.
| Name | Required | Description | Default |
|---|---|---|---|
| group_by | No | category | |
| start_date | No | ||
| end_date | No |
| 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 full burden of behavioral disclosure. It states the aggregation function but doesn't mention whether this is a read-only operation (implied but not explicit), what permissions are required, how date ranges work (inclusive/exclusive), whether null dates mean 'all time', or what the output format looks like. For a summary tool with zero annotation coverage, this leaves significant behavioral gaps.
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 - a single sentence that efficiently communicates the core functionality. Every word earns its place: 'Summarize' (action), 'total spending' (resource), 'grouped by' (operation), and the two grouping options. There's no wasted verbiage or redundancy.
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 moderate complexity (aggregation with date filtering), no annotations, and the presence of an output schema (which handles return values), the description is minimally adequate. It covers the primary function but lacks important context about date parameter usage, behavioral constraints, and differentiation from sibling tools. The output schema existence prevents this from being a complete failure.
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 description mentions the 'group_by' parameter options ('category' or 'month'), which adds meaning beyond the schema's 0% description coverage. However, it doesn't explain the date parameters (start_date, end_date) at all - their purpose, format, or what happens when null. With 3 parameters total and only partial coverage in the description, this meets the baseline for moderate schema coverage compensation.
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 purpose with a specific verb ('Summarize') and resource ('total spending'), and specifies the grouping options ('by category or month'). It distinguishes this from siblings like list_expenses (which likely lists individual items) and get_budget_status (which focuses on budget metrics). However, it doesn't explicitly mention expense data as the resource, though this is implied.
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 doesn't mention when to choose get_expense_summary over list_expenses (for aggregated vs detailed views) or get_budget_status (for spending vs budget comparison). There's no context about prerequisites, data scope, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List expenses with optional filters. Date format: YYYY-MM-DD.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | ||
| start_date | No | ||
| end_date | No | ||
| limit | No |
| 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 full burden for behavioral disclosure. It mentions optional filters and date format, but fails to address critical behavioral aspects: whether this is a read-only operation (implied but not stated), pagination behavior (limit parameter exists but not explained), authentication requirements, rate limits, or what happens when no filters are applied. For a tool with 4 parameters and no annotation coverage, this is insufficient.
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 only two sentences that each serve clear purposes: stating the tool's function and specifying date format. There's zero wasted language, and the most critical information (date format) is appropriately included. This is a model of efficient description writing.
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 has an output schema (which handles return values), 4 parameters with 0% schema coverage, and no annotations, the description is minimally adequate. It covers the basic purpose and date format but misses important context: no guidance on usage versus siblings, incomplete parameter semantics, and insufficient behavioral transparency for a filtering/list tool. The output schema reduces the burden, but significant gaps remain.
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 value by specifying the date format (YYYY-MM-DD) for date parameters, which isn't in the schema. However, it doesn't explain the 'category' parameter's possible values, the 'limit' parameter's purpose (pagination vs result limiting), or the relationship between start_date and end_date. The description provides some semantic context but leaves significant gaps.
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 ('List') and resource ('expenses'), making the purpose immediately understandable. It distinguishes from siblings like 'add_expense' or 'delete_expense' by focusing on retrieval rather than modification. However, it doesn't specify whether this lists all expenses or has a default scope, which prevents a perfect score.
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 like 'get_expense_summary' or 'export_expenses'. It mentions optional filters but doesn't explain when filtering is appropriate or what scenarios warrant this tool over others. This leaves the agent without clear decision-making criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set or update the monthly budget limit for a category.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | ||
| monthly_limit | Yes | ||
| currency | No | USD |
| 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. While 'set or update' implies a mutation operation, it doesn't specify whether this requires admin permissions, if changes are reversible, what happens to existing budgets, or any rate limits. This leaves significant gaps in understanding the tool's behavior and risks.
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, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It is appropriately sized and front-loaded, 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?
Given that there is an output schema (which handles return values), the description doesn't need to explain outputs. However, for a mutation tool with 3 parameters, 0% schema coverage, and no annotations, the description is incomplete—it lacks details on permissions, error cases, and parameter semantics, making it only minimally 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?
Schema description coverage is 0%, meaning none of the parameters are documented in the schema. The description mentions 'category' and 'monthly budget limit', which loosely map to the 'category' and 'monthly_limit' parameters, but it doesn't explain what a 'category' entails (e.g., predefined list or free text) or the format for 'monthly_limit' (e.g., positive number). The 'currency' parameter is not addressed at all, failing to compensate for the low 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 verb ('set or update') and resource ('monthly budget limit for a category'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_budget_status' or 'update_expense' which might also relate to budget management, preventing a perfect score.
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. For example, it doesn't clarify if this should be used instead of 'update_expense' for budget changes, or if it's for initial setup versus ongoing adjustments, leaving the agent with minimal context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update fields of an existing expense by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| amount | No | ||
| category | No | ||
| description | No | ||
| date | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 mentions 'Update fields' which implies mutation, but doesn't specify permissions needed, whether changes are reversible, rate limits, or error handling. It lacks details on what happens if fields are omitted or set to null, and the output schema exists but isn't described. This is a significant 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, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's function.
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 a mutation tool with 5 parameters, 0% schema coverage, no annotations, and an output schema (though not described), the description is incomplete. It doesn't explain behavioral aspects like side effects, error conditions, or parameter usage, and relies on the output schema for return values without context. For this complexity, more detail is needed to be fully helpful.
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 by explaining parameters. It only mentions 'ID' and 'fields' generically, without detailing the specific fields (amount, category, description, date) or their semantics (e.g., format for date, handling of null values). This leaves 5 parameters largely undocumented, failing to add meaningful context 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 action ('Update fields') and resource ('an existing expense by ID'), making the purpose unambiguous. It distinguishes from siblings like 'add_expense' (create) and 'delete_expense' (remove), though it doesn't explicitly contrast with them. The verb+resource combination is specific but lacks detail on which fields can be updated.
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 is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., expense must exist), exclusions, or comparisons to siblings like 'add_expense' for creation or 'list_expenses' for viewing. The description only states what it does, not when it's appropriate.
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_expenseexport_expensesget_budget_statusget_expense_summarylist_expensesset_budgetupdate_expenseScored across 8 tools
Each tool has a clearly distinct purpose with no overlap: adding, deleting, updating, listing, summarizing, exporting expenses, and managing budgets. The descriptions specify unique actions (e.g., add vs. update) and resources (expenses vs. budget), eliminating ambiguity.
All tools follow a consistent verb_noun pattern (e.g., add_expense, delete_expense, get_budget_status). The naming is uniform across all eight tools, using snake_case and clear action verbs aligned with their functions.
With 8 tools, the server is well-scoped for an expense tracker, covering core operations like CRUD for expenses, budget management, summarization, and export. Each tool earns its place without being excessive or sparse.
The tool set provides complete coverage for the expense tracking domain: full CRUD for expenses (add, delete, update, list), budget management (set and status), summarization, and export. There are no obvious gaps, enabling agents to handle typical workflows end-to-end.
Track expenses from your AI chat: log, categorize, monthly CSV reports. All data is local.
Track budgets from your AI chat: envelopes, monthly limits, variance reports. All data is local.
Personal finance, bank account, and shared memory connector for Claude, ChatGPT, Gemini Spark & more
Personal finance ledger for AI agents — query spending, track bills, forecast cash flow.
