The SAF-T MCP server presents a well-organized domain-specific toolkit with consistent naming patterns and reasonable descriptions. All 13 tools follow verb_noun naming conventions (saft_load, saft_validate, saft_query_*). However, the server has significant gaps in output schema documentation, error handling guidance, and parameter validation depth. Tool descriptions range from adequate (100-150 chars) to good (200-300 chars), meeting the 10-1024 char baseline. Input schemas are present and properly typed for all tools. The main deficiency is the absence of documented return/output schemas, critical for helping LLMs understand what data they receive and how to chain tools. Parameter descriptions are generally present but sometimes lack constraint details (e.g., saft_query_invoices doc_type values are documented in description but not as enum; date formats are mentioned but no pattern validation shown). Error handling is minimal, no recovery guidance, no categorization of retryable vs. fatal errors, and no suggestion for next steps when a tool fails.

• Document output schemas for all tools. Add a 'Returns' or 'Output' section to each tool's docstring with a JSON-like structure showing field names, types, and descriptions. E.g., for saft_summary: 'Returns {revenue: float, invoice_count: int, vat_breakdown: [{rate: string, total: float}], top_customers: [{name: string, amount: float}]}'.
• Convert all enum-like parameters to formal enum schemas in the input JSON Schema. For saft_query_invoices, change doc_type from {type: string, description: ...} to {type: string, enum: ["FT", "FR", "NC", "ND", "FS"], description: ...}. Apply to doc_type, status, group_by, product_type, checks, and metrics.
• Add numeric bounds (minValue, maxValue) to all numeric parameters in schemas. E.g., limit: {type: integer, minimum: 1, maximum: 500, default: 50}. Add format: 'date' or pattern: '^\d{4}-\d{2}-\d{2}$' to date parameters.
• Add error-handling to all tools beyond saft_load. Document what errors are possible (file not found, invalid format, constraint violation) and what the LLM should do next. E.g., 'If invoice not found, try saft_query_invoices to find the correct invoice number.'
• For saft_export, formalize the filters parameter as an object schema with defined properties matching each query tool (e.g., filters can contain {date_from, date_to, customer_nif, status, ...}).
• Update saft_export description to explicitly state it is a write operation and warn about overwriting existing files.
• Add a dependency hint to saft_load: 'Call this tool first to load a SAF-T file before using query or validation tools.'