This server has significant definition quality gaps. Tool names lack consistent verb-noun structure (e.g., 'filterInvoices', 'registerPayment' mix patterns). Most descriptions are present but very brief (10-40 chars), below the 50-200 char baseline for LLM optimization. Input schemas exist but are sparse: many tools have empty input objects (getOpenInvoices, generateInvoiceSummary, getLastWebhookEvent) with no parameters documented. Parameter descriptions are minimal or missing type details. Output schemas are not documented anywhere in the source. Error handling is minimal, most functions return generic success/failure without recovery guidance. The webhook handler functions (handlePaymentRegistered, etc.) are defined in code but tool registration is not visible, so their actual MCP exposure is unclear.

• Add explicit input schemas to all 9 tools with empty inputs. Even no-parameter tools should declare 'input: {type: "object", properties: {}, required: []}' for clarity.
• Expand all descriptions to 50-200 chars. Include WHAT the tool does, WHEN to use it, and any prerequisites. Example: 'Retrieve all open and overdue invoices for the current administration. Use this to get a quick overview before filtering by amount or date. Returns invoice list with ID, amount, due date, and status.'
• Document output schemas for all tools. Specify returned fields, types, and whether results are paginated. Example for getOpenInvoices: 'Returns {invoices: [{id: string, amount: number, due_date: string, status: string}], total: number}'.
• Enhance error responses with recovery guidance. Instead of {success: false, message: 'Error'}, return {success: false, error: 'Invoice not found', suggestion: 'Call getOpenInvoices() to list available invoices', retryable: false}.
• Add parameter constraints and enums. For example, filterInvoices criteria should declare sort_by as enum: ['amount', 'due_date', 'status'] and order as enum: ['asc', 'desc'].