Four tools with basic descriptions and Zod schemas present. However, schemas are minimal (1-3 params each, no explicit output documentation), descriptions lack depth and context for LLM selection, and error handling is generic catch-all with no recovery guidance. No parameter validation constraints (enums, ranges), no batch variants, and responses are unstructured text rather than typed objects. Tool names are clear action verbs (get_, search_), but the implementation relies on string formatting rather than structured output patterns. The server reads transaction/budget data from Lunchmoney API but does not guide the LLM on when to use each tool vs. alternatives, e.g., distinction between get-recent-transactions (time-based) and search-transactions (keyword-based) is not well explained.

• Add explicit output schemas to all tools. Define return type as object with typed fields (e.g., { transactions: [{ id, date, payee, category, amount }], total_count, next_cursor? }).
• Expand descriptions to 100-200 chars. For each tool, answer: What does it do? When to use instead of similar tools? What does it return? Example: 'Get transactions from the past N days, sorted by date. Use this to see recent spending. Returns up to LIMIT transactions with id, date, payee, category, amount, and notes.'
• Add parameter constraints: days (min 1, max 365), limit (min 1, max 100), category (enum of valid category names fetched from API on init or hardcoded list).
• Implement enum validation for category parameter in get-category-spending. Either fetch available categories on server startup and expose as enum, or return actionable error: 'Invalid category. Available: [Food, Transport, Utilities, ...]'.
• Enhance error responses with recovery guidance. Example: 'Failed to fetch budget data: Invalid date format. Expected YYYY-MM-DD. Check start_date and end_date parameters.' Or: 'API authentication failed. Verify LUNCHMONEY_TOKEN is set correctly.'
• Add pagination cursors or offset/limit to get-recent-transactions and search-transactions. Return total_count and next_cursor so agents can fetch additional results without re-querying.
• Document the semantic difference between get-recent-transactions (time-window-based) and search-transactions (keyword-based). Clarify search scope: 'Searches payee names and transaction notes. Does not search category or date. Use get-recent-transactions for date-range queries.'