18 tools with consistent verb_noun naming (create_*, all WRITE operations). Descriptions present and substantive (avg ~150 chars), explaining what each tool does. Schemas use Zod with type definitions and parameter descriptions. However, significant gaps: (1) Many tools accept raw 'object' types with minimal nested schema detail (create_bill, create_customer, create_estimate, create_purchase, create_journal_entry, create_bill_payment accept generic 'billPayment'/'customer'/'estimate'/'purchase'/'journalEntry' objects with only high-level descriptions). (2) Output schemas not documented, responses are text-wrapped JSON with no formal schema declaration. (3) No error recovery guidance, errors return plain text messages without actionable next steps. (4) No idempotency hints or confirmation patterns for destructive operations. (5) Tool descriptions lack dependency hints (e.g., 'Call search_tax_codes first if you need a tax code ID'). Strengths: consistent naming, all params described, good use of enums (e.g., create_payment_method.type, create_credit_memo.global_tax_calculation), detailed parameter constraints in descriptions (e.g., create_attachable MIME types, file size limits).

• Expand generic 'object' schemas. For create_customer, create_bill, create_estimate, create_employee, create_purchase, and create_journal_entry, define explicit nested Zod schemas with required/optional fields. Example: create_customer should have z.object({ DisplayName: z.string(), PrimaryTaxIdentifier: z.string().optional(), ... }) instead of z.object({ customer: z.object({ ... }) }).
• Document output schemas for all tools. Add a 'returns' field to each ToolDefinition specifying the response structure (e.g., { id: string, name: string, created_at: string }). Include this in tool descriptions so LLMs know what fields to expect.
• Add error classification and recovery guidance. Wrap error responses with { isError: true, error: string, classification: 'retryable'|'user_fixable'|'fatal', suggestion: string }. Example: 'Customer not found. Try search_customers() with a partial name.'
• Implement confirmation pattern for WRITE operations. Add an optional 'confirm' boolean parameter (default false) to all create_* tools. When false, return a dry-run summary; when true, execute. Or add a separate 'preview_*' tool for high-risk operations.
• Add dependency hints to tool descriptions. For create_invoice, add: 'If you only have a customer name, call search_customers() first to get the customer_ref. For tax codes, call search_tax_codes().' Repeat for create_credit_memo, create_estimate, create_purchase_order.