Tally MCP has clear, action-oriented tool names (start_household, record_expense, settle_up) and reasonable descriptions (avg ~80 chars). All 8 tools have descriptions and input schemas with typed parameters. However, parameter descriptions are sparse or missing context (e.g., 'split_between' lacks guidance on behavior when omitted). Output schemas are not documented, callers cannot predict response structure. Error handling exists but lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Composition is sound: tools are single-purpose and chainable. Security: no secrets in params, but no audit logging visible.

• Add ToolAnnotations to all tool definitions: mark read-only tools with readOnlyHint=true, destructive tools (record_expense, settle_up, start_household) with destructiveHint=true, and undo_last with idempotentHint=true. This enables LLMs to reason about safety.
• Document output schemas in tool descriptions. E.g., 'Returns a LedgerView object with fields: household (str), summary (str), balances (list of {name, minor, display}), settle (list of {from, to, minor, display})'.
• Enhance parameter descriptions with constraints and examples. E.g., 'split_between: Array of member names (must exist in household; if empty or omitted, defaults to all members). Example: ["Alice", "Bob"]'.
• Add recovery guidance to error messages. E.g., 'You don't have a household yet. Call start_household with a name and currency to create one.'
• Enforce and document result limits. E.g., 'recent_activity returns up to 100 entries (limit parameter capped at 100). For large histories, use pagination via offset parameter (not yet implemented).' Add offset/page_size params if needed.