An MCP server for tracking and managing expenses with database storage and category organization.
The ExpenseTracker server has three well-named tools with basic descriptions and partial schemas. However, it suffers from several critical gaps: (1) parameter descriptions are minimal or missing context about formats and constraints; (2) output schemas are completely undocumented, the LLM cannot predict what fields will be returned; (3) no error handling or recovery guidance; (4) date format assumptions are implicit rather than explicit; (5) no validation of inputs (e.g., amount must be positive, dates must be valid). Tools are simple and focused (good), but the lack of structured output documentation and minimal parameter guidance significantly limit agent reasoning. The average tool score is 52 (add_expense=54, list_expenses=52, summarize=50).
Add a new expense entry to the database.
List expense entries within an inclusive date range.
Summarize expenses by category within an inclusive date range.
Output schemas completely undocumented. LLMs cannot predict what fields list_expenses and summarize return. add_expense returns {status, id}, but this is inferred from code, not documented in the schema.
Date parameter format is implicit. 'date', 'start_date', 'end_date' lack format specification (ISO 8601? YYYY-MM-DD? Timezone-aware?). Agents will guess and produce invalid dates.
Missing numeric constraints. 'amount' parameter has no minimum (must be > 0), no maximum, no decimal precision guidance. Agents could pass negative amounts or absurdly large values.
No error handling or recovery guidance. If date parsing fails, SQL injection occurs, or category validation fails, the LLM gets a raw exception. No actionable error messages to guide the agent's next step.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Category parameter in add_expense has no constraint. Should be an enum or reference to the categories resource. Agents will hallucinate invalid categories.
No pagination on list_expenses. If the date range contains thousands of expenses, the tool returns all of them, bloating the response and exhausting context. No limit or offset parameters.
SQL injection vulnerability. The 'category' parameter in summarize is directly interpolated into the SQL query. Although parameterized queries are used, the check 'if category:' allows the value through without validation.