This is a domain-specific translation library, not an MCP server. No MCP protocol implementation detected in source. Tool definitions exist as TypeScript exports but lack formal MCP registration, schemas, and descriptions. Most tools have minimal descriptions (10-50 chars), no visible input schema validation, and no error handling guidance. The sandbox mock-server uses Express, not MCP transport. This appears to be a utility library being evaluated as if it were an MCP server.

• Implement MCP server wrapper: create an MCP server that exposes these 12 tools via the MCP protocol (Streamable HTTP or SSE transport). Register each tool with Tool.name, Tool.description, and Tool.inputSchema.
• Expand tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to use it (e.g., 'Call this after receiving an Open Banking payment webhook'), and what it returns. Example: 'Translates an Open Banking UK domestic payment request into an ISO 20022 pain.001 XML message. Use this when you receive a payment initiation from an OBIE-compliant API. Returns the XML message and any mapping warnings.'
• Document input and output schemas formally. For each tool, define a JSON Schema for inputs (with type, description, required, enum/pattern constraints) and outputs (with field names, types, and descriptions). Make these visible in the MCP tool registration.
• Add error handling with recovery guidance. Wrap tool calls in try-catch, validate inputs (e.g., sort code format, currency codes), and return errors like 'Invalid sort code format: expected XX-XX-XX or XXXXXX. Got: ABC. Please correct and retry.' instead of generic 400 errors.
• Add parameter constraints and enums. For tools like mapPurposeCode, document valid OB codes (BKDF, SECU, TMMF, etc.) as an enum. For convertSortCodeToIBAN, validate sort code format and account number length (8 digits) with clear error messages.