Server has 8 tools with complete input schemas and descriptions, but quality is inconsistent. Naming follows verb_noun convention well (get_*, create_*, send_). Descriptions are present but often generic (avg ~80 chars, below 194-char baseline). Schemas are properly typed with enums where appropriate, but lack output schema documentation. No error handling guidance, no parameter validation rules, and no security considerations documented. Missing tool annotations (readOnlyHint, destructiveHint). Composition is reasonable, tools are single-purpose, but descriptions don't explain when to use each tool vs. alternatives.

• Add output schemas to all tools. Document the structure of returned invoices, expenses, and reports. Example: 'Returns array of {id, customer_name, amount, status, date, due_date}' for get_invoices.
• Expand tool descriptions to 150 - 250 chars. Explain WHAT the tool does, WHEN to use it, and what it returns. Example: 'Retrieve invoices with optional filtering by status, customer, date range, or amount. Returns paginated list of invoice objects with ID, customer, amount, status, and due date. Use this to find specific invoices before sending or updating.'
• Add tool annotations: mark read-only tools with readOnlyHint=true (get_*, profit_and_loss, balance_sheet, cash_flow) and write tools with destructiveHint=true (create_*, send_invoice). Mark idempotent operations with idempotentHint=true.
• Document parameter constraints in descriptions. For date fields: 'ISO 8601 format (2024-01-15) or natural language (last month, Q1 2024)'. For limit: 'Number of results to return (1 - 100, default 20)'. For enums, replace examples with formal constraints.
• Add error handling guidance. Example for send_invoice: 'If invoice not found, call get_invoices() first to verify the ID. If email fails, check that the customer has a valid email address on file.'

Inferred effective spec: <=2025-11-25.

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