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-mcp show my expenses for 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.
Personal Expense Tracker as an MCP Server — works with Claude Desktop, Cursor, nanobot, Windsurf, and any MCP-compatible client.
📝 Track expenses & income with categories and descriptions
📊 Spending summaries — today, week, month, year
💳 Budget management — set limits per category, get alerts at 80%/100%
🎯 Savings goals — create goals, track progress with visual bars
📈 Spending insights — top categories, daily averages, biggest days
🗑️ Safe deletion — Pydantic-based elicitation for confirmation
🔄 Dual transport — stdio (local) + streamable HTTP (remote)
Related MCP server: expense-tracker-mcp-server
# with uv (recommended)
uv pip install git+https://github.com/justfsl50/expense-mcp.git
# with pip
pip install git+https://github.com/justfsl50/expense-mcp.git
# from source
git clone https://github.com/justfsl50/expense-mcp.git
cd expense-mcp
pip install -e .Add to %APPDATA%\Claude\claude_desktop_config.json (Windows) or ~/Library/Application Support/Claude/claude_desktop_config.json (Mac):
{
"mcpServers": {
"expense-mcp": {
"command": "uv",
"args": ["run", "expense-mcp"],
"env": {
"DATABASE_URL": "sqlite:///expenses.db",
"CURRENCY": "₹",
"DEFAULT_USER": "me"
}
}
}
}Same config — paste into MCP settings under the respective app.
{
"mcp": {
"servers": [{
"name": "expense-mcp",
"command": "uv run expense-mcp"
}]
}
}python server.py http
# Server runs at http://127.0.0.1:8000/mcpVariable | Default | Description |
|
| SQLite or PostgreSQL URL |
|
| Currency symbol |
|
| User ID for multi-user setups |
PostgreSQL example:
DATABASE_URL=postgresql://user:pass@localhost:5432/expensesTool | Description | Read-only |
| Save expense or income | ❌ |
| Filter by text, date, category, amount | ✅ |
| today / week / month / year totals | ✅ |
| Delete with Pydantic confirmation prompt | ❌ |
| Spending patterns and top categories | ✅ |
| Set monthly category budget | ❌ |
| View budgets with usage % | ✅ |
| Create savings goal | ❌ |
| Add money toward goal | ❌ |
| View goals with progress bars | ✅ |
URI | Description |
| Current month summary |
| This month's budgets |
| All savings goals |
Prompt | Title | Description |
| Monthly Review | Start a full month spending review |
| Budget Setup | Auto-suggest budgets from history |
| Savings Plan | Create a plan for a savings goal |
Just talk naturally in any MCP client:
"spent 500 on groceries"
"show food expenses this week"
"how much did I spend last month?"
"set food budget to 5000"
"am I within budget?"
"save 1000 toward my iPhone goal"
"give me spending insights"
"delete expense #12"MCP SDK v1.26.0 with FastMCP + json_response=True
Typed lifespan — DB engine managed via AppContext dataclass
SQLAlchemy 2.0 — DeclarativeBase, sessionmaker
Pydantic v2 — input validation, elicitation schemas
Tool annotations — readOnlyHint, destructiveHint, idempotentHint
Context logging — ctx.info(), ctx.warning() in tools
expenses — id, user_id, amount, category, description, type, date, source, created_at
budgets — id, user_id, category, amount, month
goals — id, user_id, name, target, saved, deadlineMIT — free to use, modify, and distribute.
Get all budgets and current spending for this month.
Returns: Formatted budget list with usage percentages and status indicators.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context by specifying the result format ('usage percentages and status indicators') and temporal scope ('this month'), going beyond what annotations provide.
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?
Two sentences with no wasted words. The first sentence declares the primary action and scope; the second describes the return format. It is front-loaded and 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?
Given the simple zero-parameter tool and the presence of an output schema, the description covers the key aspects: what it does, the temporal scope, and the return format. It is mostly complete, though it could note if this includes all user-level budgets or workspace-level.
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 has zero parameters, so schema coverage is 100% (trivially). The description does not need to explain parameters; it instead clarifies the tool's output. This meets the baseline of 4 for zero-parameter tools.
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 'Get all budgets and current spending for this month,' specifying the action ('Get'), resource ('budgets and spending'), and temporal scope. It distinguishes from sibling tools like 'budget_set' and 'expense_add' which are mutative or expense-specific.
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 or when-not-to-use guidance is given. While the name and description imply retrieval, there is no mention of alternatives or exclusions among siblings such as 'budget_set' (settings) or 'expense_summary'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set or update a monthly budget for a spending category.
Args: params: BudgetInput with category, amount, and optional month.
Returns: Confirmation of budget set.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent, non-destructive, read-write. Description adds 'Set or update' consistent with annotations but does not elaborate on side effects or error scenarios.
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?
Single sentence followed by docstring-style Args/Returns. Every word is necessary and well-structured.
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 an output schema present, description adequately covers purpose and return type. Could mention border cases like update vs create, but sufficient for a simple set operation.
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 has descriptions for amount and month (but top-level params lacks description). Description lists the three fields but adds no new meaning beyond 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?
Description clearly states verb (set/update) and resource (monthly budget for a spending category). Distinct from siblings like budget_list (list budgets) and expense tools.
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 on when to use this tool vs alternatives, such as when to set vs update a budget, or prerequisites like checking existing budgets with budget_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a new expense or income transaction.
Args: params: AddExpenseInput with amount, category, description, type, date.
Returns: Confirmation string with saved details and optional budget alert.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false) and non-destructiveness. The description adds that it returns a confirmation with details and an optional budget alert, but does not disclose other traits like duplicate handling or validation beyond the schema.
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 very concise: two sentences. The first sentence states the purpose, the second briefly describes Args and Returns. No wasted words.
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 creation tool, the description covers purpose, input shape, and return format. It lacks details like prerequisites (e.g., budget setup for alerts) but is otherwise adequate given schema richness.
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 has high internal coverage (descriptions for each property: amount, category, etc.). The description lists the parameters but adds no new semantics beyond summarizing them, so baseline 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 'Save a new expense or income transaction' uses a specific verb 'Save' and clearly identifies the resource (expense/income transaction). It distinguishes this creation tool from sibling tools like expense_search, expense_delete, etc.
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 does not provide explicit when-to-use or when-not-to-use guidance. It implies its role as a creation tool relative to siblings, but lacks direct alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete an expense by ID. Asks for confirmation first.
Args: expense_id: The ID of the expense to delete (from expense_search results).
Returns: Confirmation or cancellation message.
| Name | Required | Description | Default |
|---|---|---|---|
| expense_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds that deletion is permanent and requires confirmation, and notes the return type (confirmation or cancellation). No contradictions.
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 very concise: two sentences for the main purpose, followed by clearly labeled Args and Returns sections. No unnecessary words.
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 deletion tool with one parameter and an output schema (implied), the description covers the action, confirmation behavior, and return type. Could mention irreversibility, but the permanent nature is already stated.
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 has 0% description coverage, but the description explains the one parameter (expense_id) by sourcing it from expense_search results. This adds meaningful guidance beyond the schema's type 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 action (Permanently delete), the resource (expense), and the unique behavior (asks for confirmation). It distinguishes from sibling tools like expense_add or expense_search.
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?
Specifies that expense_id should come from expense_search results, providing clear sourcing context. However, it does not explicitly state when not to use this tool or mention alternatives for non-permanent actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get spending patterns and insights for the current month.
Returns: Key spending metrics: top category, daily average, biggest day, anomalies.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, non-destructive, idempotent), the description specifies that results are for the current month and includes return metrics like anomalies. This adds useful behavioral context, though it could detail anomaly detection criteria.
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 (two sentences) and front-loaded with the main purpose, followed by a clear list of return values. No superfluous content.
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 there are no parameters and an output schema exists, the description sufficiently explains the return metrics. However, it lacks explanation of what constitutes an anomaly, which would be beneficial for complete 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 tool has no parameters, and the input schema provides complete coverage. The description does not need to add parameter information, so it meets the baseline expectation for parameter 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: retrieving spending patterns and insights for the current month. It distinguishes itself from sibling tools like expense_summary by focusing on insights such as top category, daily average, biggest day, and anomalies.
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 for obtaining monthly spending insights but does not explicitly guide when to use this tool over alternatives like expense_summary. No when-not-to-use or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and filter expenses with flexible criteria.
Args: params: SearchInput with optional query, category, dates, amounts, type, limit.
Returns: Formatted list of matching transactions with total.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that the tool returns a 'Formatted list of matching transactions with total,' confirming read-only behavior and output format.
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 very concise, using only two short sentences to convey purpose and parameters. The Args/Returns structure is clear and no unnecessary words.
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 and the tool is a straightforward search, the description sufficiently covers what the tool does and returns. It mentions the output format, meeting completeness requirements.
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 coverage is 0% but the description lists key fields (query, category, dates, amounts, type, limit) which adds quick context. The schema already has good descriptions per parameter, so the description provides a helpful summary without repeating details.
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?
Description clearly states 'Search and filter expenses' with a specific verb and resource. It distinguishes from siblings like expense_add (adds), expense_delete (deletes), and expense_summary (aggregates).
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?
While the description implies this tool is for searching expenses, it does not explicitly state when to use it over alternatives like budget_list or expense_insights. However, the sibling names and tool name make usage fairly obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get spending summary for a time period.
Args: period: 'today', 'week', 'month', or 'year'.
Returns: Summary with totals, balance, and category breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | month |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent behavior. The description adds that it returns a summary with totals, balance, and category breakdown, which is useful. However, it does not disclose any edge cases, data recency, or limitations beyond the basic output 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?
The description is extremely concise: two sentences plus a brief Args/Returns section. The purpose is front-loaded, and every word adds value. No unnecessary 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 simple tool with one parameter and an output schema, the description covers the essential: what it does, the parameter options, and the return structure. The missing default and lack of usage guidance are minor gaps given the tool's simplicity and the presence of annotations and output schema.
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 explicitly lists the allowed values for the period parameter ('today', 'week', 'month', 'year'), which is not described in the input schema (coverage 0%). This adds meaning beyond the enum definition. However, it does not mention the default value 'month', which is present in the schema, missing an opportunity to fully inform the agent.
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 'Get spending summary for a time period', identifying the action and resource. It mentions the return includes totals, balance, and category breakdown. However, it does not differentiate from sibling tool 'expense_insights', which might also provide summary data, slightly reducing clarity.
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 like expense_insights or expense_search. No context on when not to use it or prerequisites is given, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new savings goal.
Args: params: GoalInput with name, target amount, and deadline.
Returns: Confirmation of goal creation.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it's not read-only (write operation) and not destructive, which aligns with 'create'. The description adds minimal behavioral context beyond the annotation signals.
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?
Two concise sentences with a clear front-loaded purpose. No redundant information.
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 create tool, it covers the basic aspects. An output schema exists but return is vaguely described as 'confirmation'. Could mention uniqueness constraints or future dates.
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 lists the three fields (name, target, deadline) but adds no extra detail beyond what the schema already provides. Despite schema coverage being 0% (discrepancy), the schema itself contains detailed 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?
The description clearly states 'Create a new savings goal', specifying the action (create) and resource (savings goal). It distinguishes from siblings like goal_list and goal_update.
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?
Usage is implied as creating a goal, but there is no explicit guidance on when to use this tool vs alternatives like goal_update or goal_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all savings goals with progress bars.
Returns: Formatted list of goals with progress and deadline.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (readOnlyHint, idempotentHint) and adds context about the return format ('progress and deadline'), beyond what annotations provide. It clearly states the tool returns a formatted list of goals, indicating no side effects, consistent with the annotations.
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 very concise with two sentences, front-loading the purpose and adding return details. No unnecessary words or fluff; every sentence adds value.
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 no parameters and an output schema exists, the description adequately explains the return format. It could optionally mention that the list contains all goals without filters, but it is sufficiently complete for a simple list tool. The mention of 'progress bars' adds useful context.
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?
There are no parameters, and the schema has 100% coverage. The description adds no parameter-level info because none are needed. Baseline 3 is appropriate as the description does not add meaning beyond the schema, but also does not miss anything.
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 explicitly states 'Get all savings goals with progress bars', which clearly identifies the action (get all) and resource (savings goals), with a specific detail (progress bars). It distinguishes from sibling tools like goal_create and goal_update, which involve mutation.
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 does not provide explicit guidance on when to use this tool versus alternatives. However, the name and the simple act of listing goals imply it should be used when a user wants to view all goals, without filtering or modification. No explicit exclusions or comparisons to siblings are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add money toward a savings goal.
Args: params: UpdateGoalInput with goal name and amount to add.
Returns: Updated goal progress.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (non-readOnly, non-destructive, non-idempotent), which the description complements by stating it 'adds money' (a mutation) and 'returns updated goal progress.' However, it does not disclose potential side effects or error conditions, leaving some 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 very concise: one sentence plus Args/Returns sections. No unnecessary words. Could be slightly more structured (e.g., bullet points), but it is efficient and front-loaded with the action.
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?
Output schema exists, so the return description is sufficient. However, the tool lacks context on when to use it (e.g., only for existing goals) and does not mention error handling. Given sibling tools and simple interface, it is moderately complete but not thorough.
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% for the top-level parameter, but the nested schema has descriptions for 'name' and 'amount'. The description restates that the input is an 'UpdateGoalInput with goal name and amount,' adding minimal value beyond the schema. Adequate but not compensating fully for the coverage 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 clearly states 'Add money toward a savings goal,' specifying a concrete action (add) and resource (goal). It distinguishes from sibling tools like goal_create (create new) and goal_list (list), making the 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 description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., goal must exist), nor does it clarify that this tool is only for adding funds (not updating other fields). Implicitly clear but lacking explicit context.
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.
v1.0.1budget_listbudget_setexpense_addexpense_deleteexpense_insightsexpense_searchexpense_summarygoal_creategoal_listgoal_updateScored across 10 tools
Each tool has a distinct purpose: budgeting, expenses, and goals are clearly separated. Even similar tools like expense_summary and expense_insights provide different outputs (summary vs. patterns), so no confusion.
All tools follow a consistent verb_noun pattern using snake_case, e.g., expense_add, goal_list, budget_set. The naming conventions are uniform across the entire set.
10 tools cover the three main domains (budgets, expenses, goals) without being excessive. Each tool contributes a necessary operation, making the set well-scoped for an expense management server.
The tool surface covers core CRUD operations for expenses (add, delete, search) and goals (create, list, update), but misses an expense update tool. Budgets have list and set, which covers creation and reading, but no delete. Minor gaps exist.
Log, query, and edit expenses, budgets, and accounts in Manilo from any MCP-compatible AI assistant.
Personal finance for AI agents — onboard, import statements, categorize & budget over MCP.
Log, query, and edit expenses, budgets, and accounts in Manilo (formerly Ledgy) from any MCP-compatible AI assistant.
Log, query, and edit expenses, budgets, and accounts in Ledgy from any MCP-compatible AI assistant.
