Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. list_expenses has no input parameters (empty schema), which is acceptable for a read-only discovery tool. add_expense has typed parameters with descriptions, meeting minimum requirements. However, neither tool documents output structure, error cases, or recovery guidance. Descriptions are adequate (34-52 chars) but lack context on when to use each tool or what data structures are returned. No tool annotations (readOnlyHint, destructiveHint) despite clear read/write distinction. Validation is present in code (Zod) but not reflected in schema constraints (e.g., name minLength, amount range).

• Add explicit output schema documentation to both tools. Example for list_expenses: 'Returns {content: [{type: "text", text: string}], structuredContent: {expenses: [{id: string, name: string, amount: number}]}}'.
• Add tool annotations: set destructiveHint=true on add_expense and readOnlyHint=true on list_expenses. This enables LLMs to reason about idempotency and retry safety.
• Expand add_expense schema with constraints: name should have minLength: 1; amount should have minimum: 0 (or allow negative for refunds, but document this). Use JSON Schema format, not just Zod.
• Enhance error messages with recovery guidance. Instead of 'Invalid expense: Name is required', return 'Invalid expense: Name is required. Provide a non-empty string (1-100 characters).'
• Expand tool descriptions to 100-150 characters. Example: 'Adds a new expense item. Provide a name (1-100 chars) and numeric amount. Returns updated expense list with the new item added.'

Inferred effective spec: 2025-06-18+.

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained