Enum constraints listed in descriptions but not enforced as JSON Schema enums. Parameters like 'category' (Food|Travel|Shopping|Bills|Entertainment|Health|Other), 'period' (today|yesterday|this week|...), and 'payment_method' (cash|upi|card|netbanking|other) are mentioned in text descriptions but not declared as JSON Schema enum types. LLMs cannot parse constraints from descriptions reliably and may invent invalid values.

Output schemas are not formally documented. All tools return string responses, but the structure of those strings (fields, order, totals, IDs) is inferred from the code, not declared in tool output documentation. Agents cannot plan downstream operations without seeing what data is available. For example, get_expenses_by_date returns formatted lines with IDs, but LLMs cannot programmatically extract the ID field without parsing unstructured text.

Error handling is minimal. Tools return success-only string responses. No error classification (retryable vs user-fixable vs fatal), no actionable error messages with recovery hints, no structured error reporting. For example, if get_expenses_by_date finds no expenses, it returns 'No expenses found on 2026-02-24.' but provides no guidance on what the agent should do next, ask the user for a different date? Try a wider period? This forces the agent to guess.

Inconsistent and redundant month/year parameter design. set_budget uses 'month' (YYYY-MM), summarize_by_month uses separate 'month' (two digits) and 'year', get_budget uses 'month' (YYYY-MM) and 'year' (four digits). This inconsistency forces LLMs to reason about which format each tool expects and increases the chance of type mismatches or wrong parameters. The month format should be standardized across all tools.

Format constraints embedded in descriptions but not enforced. Descriptions mention 'Date in YYYY-MM-DD format' and 'Month in YYYY-MM format', but these are not validated via regex patterns in the schema. LLMs may send '2026/02/24' or '02-24-2026' without catching the error from the description text alone.

Tool name 'delete_expense_tool' includes the redundant word 'tool'. The pattern verb_noun (delete_expense) is clearer. This minor naming issue reduces discoverability and conflicts with the convention of dropping framework words from tool names.

No pagination for list_all and list_expenses. If the user has hundreds or thousands of expenses, these tools will return massive unstructured text responses that blow out the context window. No limit parameter, no offset/page support, no total count returned for planning. The tool descriptions do not warn about result limits.

No tool annotations for destructive/read-only operations. delete_expense_tool is destructive and should have a destructiveHint=true annotation. get_expenses_by_date, list_expenses, list_all, summarize_expenses, summarize_by_month, and get_budget are read-only and should have readOnlyHint=true. Annotations help clients and agents reason about side effects and safety.

No validation of mutual exclusivity or dependency relationships documented. For example, set_budget and get_budget have both 'month' and 'year' parameters, but the description does not clarify the relationship or warn if they mismatch. Similarly, edit_expense accepts partial updates but does not document which fields can be omitted or how partial updates behave (e.g., if only 'amount' is passed, are other fields retained?).

Missing prerequisite documentation for tools. While delete_expense_tool documents its workflow clearly, other tools that depend on get_expenses_by_date (edit_expense, delete_expense_tool) should be more explicit that the user must call get_expenses_by_date first and select an expense ID from that output. This prevents agents from trying to guess or hallucinate expense IDs.