MoneyWiz MCP has good structure with 10 tools clearly registered in server.go. All tools have descriptions (194-char average is above the 34-char p10 baseline), proper JSON Schema registration with typed properties, and consistent naming using action verbs (list_, get_, analyze_, calculate_). However, several critical gaps prevent a higher score: (1) output schemas are completely undocumented, the code shows tool registration but no return type documentation in either the schema definitions or function signatures visible in the excerpt; (2) most tools lack parameter descriptions in the schema itself (e.g., list_accounts and list_categories have empty Properties maps in their InputSchema); (3) no evidence of error handling patterns or recovery guidance in the visible code; (4) tool descriptions do not explain WHEN to use each tool versus similar ones (e.g., analyze_spending_trends vs get_financial_stats distinction is unclear); (5) security and audit patterns are not visible (no evidence of logging, permission checks, or input validation). The tools themselves are well-named and clearly focused on financial analysis, with good domain separation. List and analysis tools appropriately note multi-currency handling and omit currency conversion. However, without visible output schema documentation and parameter validation guidance, agents will struggle to chain these tools effectively.

• Add documented output schemas for all 10 tools. Each handler should return a JSON structure with typed fields. For example, list_accounts should document: [{ account_id: int, account_name: string, balance: float, currency: string, ... }]. Include in the tool definition as 'outputSchema' (if supported by the framework) or in a separate docstring.
• Add parameter descriptions to the JSON Schema registration. In the InputSchema Properties map, add a 'description' field for each property. Example: Properties["limit"] should be { "type": "integer", "description": "Maximum results to return (1-500, default 50)" }.
• Enhance tool descriptions to clarify selection logic. For analyze_spending_trends, add: 'Use this when the agent needs to understand spending patterns over time. If per-category totals are needed without time grouping, use get_financial_stats instead.' Similar guidance for income_trends vs savings_recommendations.
• Add pagination support. list_transactions should document returning a result object like { transactions: [...], total_count: int, has_more: bool, next_offset?: int }. Implement offset-based pagination in the handler and document in the tool description.
• Add parameter constraints to descriptions. For list_transactions, expand the 'limit' description to: 'Maximum number of transactions to return (1-500, default 50). Exceeding 500 will be clamped.' For dates, add: 'Dates must be ISO 8601 format (YYYY-MM-DD). Invalid dates will return an error listing the constraint.'
• Implement and document error recovery patterns. In handler functions, return structured errors with actionable guidance. Example: 'Account 999 not found. Available accounts: [list first 5]. Call list_accounts() to see all.' Include in tool description: 'On error, the tool returns a recovery hint, follow it to self-correct.'

Inferred effective spec: 2025-06-18+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry