BudgetApp has three tools with basic descriptions and schemas, but exhibits critical quality gaps. All three tools have actual parameter schemas defined via fastmcp decorators, which is a positive; however, descriptions are duplicated/incorrect, parameter descriptions are minimal, and output schemas are entirely undocumented. The tool names follow verb_noun conventions (add_income_tool, add_expense_tool, get_summary), which is good, but lack precision, 'add_income_tool' and 'add_expense_tool' both have identical descriptions mentioning 'income', and output structures are inferred from code rather than formally declared. Error handling is weak (only ValidationError caught; no guidance for recovery). No tool annotations (destructiveHint, idempotentHint) are present. The server is STDIO-only, which does not affect Definition Quality score, but severely limits Protocol Readiness.
Tools (3)
add_expense_toolwritesource verified42/100
Add income for a month with name, amount and for which month this income for in a natural language
add_income_toolwritesource verified50/100
Add income for a month with name, amount and for which month this income for in a natural language
get_summaryread onlysource verified60/100
GET Monthly budget summary with income, expenses and balance
add_expense_tool has IDENTICAL description to add_income_tool ('Add income for a month...'), which is factually wrong. LLMs will be unable to distinguish these tools and will hallucinate the expense tool as an income tool.
All three tools lack output schema documentation. LLMs cannot plan downstream tool calls or extract fields without knowing the structure of responses. Code inspection required to infer outputs.
Parameter descriptions for 'month' ("Month in natural language") are ambiguous. No format specification (e.g., 'January', '2025-01', 'January 2025') or constraints provided. LLMs will guess and likely pass inconsistent values.
add_income_tooladd_expense_toolget_summary
HIGH
Recommendations
URGENT: Rewrite add_expense_tool description. Current text is identical to add_income_tool and factually wrong. Change to 'Add an expense for a specified month with name, amount, and date. This creates a permanent record and cannot be undone; use update_expense_tool to modify.' or similar.
Document output schemas for all three tools. For add_income_tool and add_expense_tool, declare: {"type": "object", "properties": {"status": {"type": "string"}, "data": {"type": "object", "properties": {"name": {"type": "string"}, "amount": {"type": "number"}, "month": {"type": "string"}}}}}. For get_summary, declare: {"type": "object", "properties": {"month": {"type": "string"}, "total_income": {"type": "number"}, "total_expense": {"type": "number"}, "balance": {"type": "number"}, "income_list": {"type": "array", "items": {...}}, "expense_list": {"type": "array", "items": {...}}}}.
Add format constraint for 'month' parameter. Change description from 'Month in natural language' to 'Month as YYYY-MM (e.g., 2025-01) or full natural language (e.g., January 2025). Both formats accepted; internally normalized.' Then validate and normalize inside the tool.
Improve error handling. When ValidationError is caught, return a structured error response: {"status": "error", "code": "VALIDATION_ERROR", "message": "Invalid month format. Expected YYYY-MM or full month name.", "retry": true}. This guides the LLM to self-correct rather than giving up.
Add tool annotations via fastmcp. Decorate add_income_tool and add_expense_tool with a 'destructive' or 'state_modifying' hint to signal to LLMs that these are irreversible operations. E.g., add a `destructiveHint=True` equivalent or update tool docstring to say 'WARNING: This operation is permanent and cannot be undone without manual database intervention.'
Error handling only catches ValidationError and returns minimal feedback. No guidance for LLM recovery (e.g., 'If month format is invalid, use YYYY-MM format'). Stack traces or raw error messages would appear in output.
Tool names and descriptions do not clearly state side effects. add_income_tool and add_expense_tool are WRITE operations (irreversible state changes) but descriptions do not declare this. No tool annotations (destructiveHint, idempotentHint) present.
No batch operations offered. If an agent needs to add 10 expenses, it must call add_expense_tool 10 times sequentially, wasting tokens and latency. Consider adding a bulk_add_expenses or similar tool.
add_income_tooladd_expense_tool
Add an update_income_tool and update_expense_tool for editing existing records, and a delete_income_tool and delete_expense_tool for removal (with confirmation step). This avoids forcing users to accept errors.
Consider a bulk_add_incomes_tool and bulk_add_expenses_tool that accept arrays of transactions. Prevents N sequential calls for common batch workflows.
Add a get_summary description: include what each field represents. E.g., 'Returns total income, total expenses, and net balance for the month. Also returns itemized lists of all income and expense records. Use this to audit a month\'s finances or find specific transactions.'
Validate month format early and return clear feedback if it does not match expected patterns. Do not let ambiguous month values silently fail or produce unexpected behavior.