Server has 8 tools with basic structure. Strengths: all tools have names following verb_noun convention (echo, listar-*, enviar-), descriptions present for all tools, and input schemas defined via Zod. Weaknesses: descriptions are generic and brief (10-50 chars typically), most lack parameter-level descriptions, output schemas partially documented, no error recovery guidance, and several tools lack depth in documentation. The tool framework (defineTool) provides structured output with both content and structuredContent, which is good. However, parameter descriptions are mostly missing, the 'message' param in echo has a description, but tools like listarClientesPeloDocumento likely lack per-param guidance based on code visibility. No evidence of pagination support for list_ tools despite multiple returning potentially large result sets (e.g., listarFaturasPorCliente). Error handling returns structured responses with isError flag, which is positive, but error messages lack recovery guidance.

• Add pagination to all list_ tools: include limit (default 20, max 100), offset/cursor parameters, and return {total_count, next_cursor, items[]} structure. Update descriptions to state 'Supports pagination; returns max 20 results by default.'
• Document output schemas for all 7 non-echo tools. Create explicit Zod schemas (or JSON Schema comments) defining the return structure: which fields are present, their types, and which can be chained to other tools.
• Expand all tool descriptions to 100-200 chars following the pattern: '[ACTION] [WHAT] [WHEN TO USE] [PREREQUISITES].' Example: 'Lists all invoices for a specific client. Use after identifying the client_id with listar_clientes_pelo_documento. Returns invoice_id, amount, due_date, status.'
• Add per-parameter descriptions to all tool input schemas. For each Zod field, include a description string. Example: z.object({cliente_id: z.string().describe('Numeric client ID (1-999999), obtained from listar_clientes_pelo_documento')})
• Implement input validation with actionable error messages. When cliente_id is invalid, return: 'Invalid cliente_id: must be numeric 1-999999. Got: abc123. Try listar_clientes_pelo_documento to find valid IDs.'
• Add WRITE-specific handling to enviar-fatura: (1) Accept optional dry_run boolean param, (2) Return a confirmation object with pending changes instead of executing immediately, or (3) Require explicit confirmation parameter. Document: 'This tool sends an invoice (irreversible). Confirm by passing confirm=true after review.'

Inferred effective spec: 2025-06-18+.

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