Orchestration MCP server: ISO 20022 readiness scoring, remediation, and bank-response simulation over the foundational MCP servers.
Four tools with clear verb-noun naming (list_, run_, remediate_, simulate_). All have descriptions (194 - 250 chars, within baseline 34 - 392). Input schemas present with typed parameters and descriptions. However, output schemas are undocumented, LLMs cannot predict response structure for chaining. Parameter descriptions lack format/constraint details (e.g., what constitutes a valid 'reason_code'?). Error handling and recovery guidance absent. Tool composition is sound (each does one thing), but missing pagination, result limits, and field-level documentation.
List the available clearing profiles (CBPR+, SEPA_Instant, ...). Use this to discover the ``target_profile`` values the other tools accept.
Apply automated remediation (e.g. Nov 2026 structured addresses). Args: payload_content: The raw ISO 20022 message text. target_profile: The clearing profile driving the remediation policy.
Detect, validate, profile-lint, and score a payload's readiness. Args: payload_content: The raw ISO 20022 message text. filename_hint: Optional original filename, for routing. target_profile: The clearing profile to lint against.
Emit a pacs.002 status report mocking a bank's response. Args: inbound_payload: The inbound initiation payload. desired_behavior: The status to simulate (ACCP / RJCT / PDNG). reason_code: The reason code (required when RJCT).
Output schemas undocumented. LLMs cannot predict response structure (fields, types, nesting) for downstream tool chaining or data extraction.
Parameter descriptions lack format/constraint details. 'reason_code' says 'ISO status reason code, e.g. AM04' but does not specify format (length, character set, validation rules). LLMs may pass invalid values.
No error handling or recovery guidance. Tools do not document what errors are possible, whether they are retryable, or what the LLM should do next (e.g., 'If profile not found, call list_profiles first').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
run_readiness_check and remediate_payload delegate to external servers (iso20022-mcp, camt053-mcp, etc.) but do not document dependencies, timeouts, or fallback behavior. Dockerfile comment notes these servers must be 'resolvable in the runtime environment', this is a deployment risk not surfaced in tool descriptions.
No pagination or result-limit documentation. list_profiles does not state how many profiles are returned or whether results are paginated. Large result sets could exhaust context windows.