Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
This expense tracker server has critical definition quality gaps across all dimensions. While tool names follow basic verb_noun conventions, parameter descriptions are almost entirely absent (all null in schema), and tool descriptions are missing or minimal. The server lacks input validation guidance, error handling patterns, and comprehensive output documentation. Only 1 of 4 tools has a description. Parameter types are present but not constrained (no enums for category/subcategory, no format validation for dates). Output schemas are not documented. This represents a significantly below-average MCP server implementation.
No input validation or constraints. The 'category' and 'subcategory' parameters accept free-form strings with no enum, pattern, or validation. Free-form strings invite hallucinated values.' LLMs will invent invalid category names.
add_expensesummarize
Recommendations
Add comprehensive descriptions to all four tools. Example: 'add_expense: Record a new expense entry to the database with amount, category, and date. Called to log financial transactions for later analysis and budgeting.' (50-150 chars each).
Add detailed descriptions for EVERY parameter. Example for add_expense.amount: 'The transaction amount in dollars. Must be a positive number (0.01 to 999999.99). E.g. 25.50 for a coffee purchase.' Include units, valid ranges, and constraints.
Convert category and subcategory to enums. Define a fixed set of valid categories in a JSON configuration (e.g. ["Food", "Transport", "Utilities", "Entertainment", "Other"]) and pass to LLMs via a resource or tool parameter validation.
Add date format specification. Update date parameter descriptions: 'Date in ISO 8601 format (YYYY-MM-DD). E.g. 2025-01-15. Must be valid calendar date; future dates rejected.' Add explicit validation in code: reject malformed dates with clear error message.
Document output schemas for all list and summary tools. Example for list_expenses return: 'Array of objects, each with fields: id (integer), date (string, YYYY-MM-DD), amount (float), category (string), subcategory (string), note (string). Max 50 items per request (see pagination).'
Add pagination to list_expenses and list_expenses_bydate. Introduce parameters: limit (default 20, max 100) and offset (default 0). Return: {"items": [...], "total": 1250, "limit": 20, "offset": 0}. Prevents context window overflow.
Implement structured error handling. Return JSON errors with: {"error": "invalid_category", "message": "Category must be one of: Food, Transport, Utilities, Entertainment, Other. Got: 'Foo'.", "suggestion": "Did you mean 'Food'?"} per pattern:recovery-guide.
Date parameters ('date', 'start_date', 'end_date') have no format specification or validation guidance. LLMs cannot read JSON Schema pattern fields, they rely on the description text to understand constraints.' LLMs will pass malformed dates.
No output schemas documented. LLMs need to know what fields to expect so they can plan downstream tool calls.' LLMs cannot reason about the structure of results returned by list_expenses, list_expenses_bydate, or summarize.
No pagination for list_expenses and list_expenses_bydate. Without pagination, large results blow the context window.' An expense tracker with years of data will return thousands of records, exhausting context.
Tool 'add_expense' uses readOnlyHint=False but other tools do not specify annotations. Per spec (2026-07-28), tool annotations (readOnlyHint, destructiveHint, idempotentHint) should be consistently applied to all tools for LLM planning. list_expenses_bydate and summarize should have readOnlyHint=True explicitly.
list_expenseslist_expenses_bydatesummarize
Add idempotentHint and destructiveHint annotations. Example: list_expenses should have {"readOnlyHint": true, "idempotentHint": true}; add_expense should have {"readOnlyHint": false, "destructiveHint": false} (correct, since it creates but doesn't delete).
Add input validation in code. Reject: amount <= 0, date not YYYY-MM-DD, category not in whitelist, category/subcategory > 50 chars. Return actionable error messages, not bare exceptions.
Consider adding a list_categories tool or expense://categories resource output to help LLMs discover valid category values automatically (already partially present as expense://categories resource, document it in tool descriptions).