Pain001 MCP server defines 5 tools with clear domain focus (ISO 20022 payment file generation). All tools have descriptions (10 - 200 chars, within baseline 34 - 392 range) and input schemas with type definitions. However, output schemas are undocumented, LLMs cannot infer what fields to expect from responses. Parameter descriptions are minimal (e.g., 'Payment rows as a list of dicts' lacks format/structure guidance). No error handling guidance, no enum constraints on message_type despite known valid values (pain.001.001.03, etc.), and no recovery hints. Tool names follow verb_noun pattern (list_, inspect_, generate_, validate_) but lack specificity, 'inspect_template' is vague; 'describe_message_type_columns' would be clearer. Missing: pagination for list_supported_versions, per-item error reporting for batch operations, and actionable error messages.

• Document output schemas for all 5 tools. Example: 'Returns: {"versions": [{"type": "string", "description": "ISO 20022 message type (e.g. pain.001.001.03)"}, {"supported_profiles": ["string"], "description": "Payment schemes this type supports (sepa-sct, sepa-sdd, etc.)"}]}'
• Convert message_type parameter to enum with all valid ISO 20022 pain.001 and pain.008 variants. Prevents LLM hallucination and enables autocomplete.
• Expand 'rows' parameter description with concrete schema: 'Array of payment transaction objects. Each object must include: creditor_name (string, 1-70 chars), creditor_iban (string, valid IBAN), amount (decimal, > 0), currency (ISO 4217 code, e.g. EUR), debtor_name (string), debtor_iban (string). Optional: reference, remittance_info.'
• Add error recovery hints to tool descriptions. E.g., generate_payment_file: 'If validation fails, call validate_payment_data first to identify row-level errors. Returns per-row error details with field names and constraints violated.'
• Add pagination to list_supported_versions: accept limit (1-100, default 20) and offset parameters; return {"versions": [...], "total": int, "offset": int, "limit": int}.