ValidationException in agentic MCP clients (e.g. Kiro CLI, Claude Desktop) since 1.3.0 release

[Juanap12]

Since 1.3.0 release we're getting errors caused my ReportPortal MCP Server when trying to interact with agents:

request_id: e671f6e3-8197-48c7-b640-2c37282d71e8, error: An unknown error occurred: ValidationException

These were our findings:

Technical Report: Compatibility Issues in MCP Server v1.3.0
IMPORTANT
Summary of Findings: The 1.3.0 release introduces schema complexities and naming inconsistencies that trigger ValidationException errors in agentic MCP clients (like Kiro/Claude Desktop).

1. Schema Validation Failure (anyOf)
   The update_launch tool uses an anyOf constraint at the root of its inputSchema. Many MCP clients expect a strictly flat JSON Schema and fail to parse or generate UI/Prompts for tools using logical operators (anyOf, oneOf, allOf).
   Location: update_launch -> inputSchema
   Suggested Fix: Move optional fields to the properties map and handle validation logic internally instead of relying on the schema constraint.

2. Parameter Naming Inconsistencies
   There is a mix of snake_case and kebab-case across different tools which confuses the LLM's parameter selection logic:
   get_launch_by_id uses launch_id.
   get_test_items_by_filter uses launch-id.
   Most filters use kebab-case (e.g., filter-cnt-name).
   Recommendation: Standardize on one convention (preferably kebab-case as it matches common MCP patterns, or snake_case for Go consistency).

3. Context Bloat (Long Descriptions)
   Descriptions for parameters like include-before-after-hooks are extremely verbose. When multiplied by 15+ tools, the tools/list response (18.6 KB) consumes a significant portion of the LLM's system prompt context.
   Recommendation: Shorten descriptions and move detailed documentation to the server's README.

4. The "Date Bug" (Critical)
   The server fails internally when processing responses from ReportPortal instances that return ISO8601 offsets without colons (e.g., +0000). Go's time.RFC3339 parser is strictly compliant and rejects these.
   Error: cannot parse "+0000" as "Z07:00"

debug_130_tools_response.json
debug_130_init_response.json

[AleksandrParamonoff]

@Juanap12 thanks for the detailed report and for narrowing this down to concrete causes.

These two fixes have already been implemented:

1. update_launch and root-level anyOf (PR #99)
   The update_launch tool no longer uses an anyOf constraint on its input schema. The handler still enforces that at least one of description or attributes is provided, so behavior is unchanged for valid calls, while clients that only support flat schemas should no longer hit validation issues from that anyOf pattern.

2. ISO8601 offsets without a colon / cannot parse "+0000" as "Z07:00" (PR #100)
   Timestamp parsing was extended so values like +0000 / -0500 (numeric offset without :) are accepted, along with tighter alignment to RFC3339/RFC3339Nano where appropriate, with tests added in the utilities package.

[AleksandrParamonoff]

Hi, @Juanap12 please take a look at https://github.com/reportportal/reportportal-mcp-server/releases/tag/1.3.1