zephyr_get_issue_link_test_cases always fails with "expected array, received object" schema validation error

[arshiaaflaki]

Package version: @smartbear/mcp@0.37.0 (latest as of 2026-08-20)

Tool:

zephyr_get_issue_link_test_cases

Summary:

Every call to zephyr_get_issue_link_test_cases fails client-side with a structured-output schema validation error, regardless of how many Zephyr test cases are actually linked to the issue:

Output validation error: Invalid structured content for tool zephyr_get_issue_link_test_cases: Invalid input: expected array, received object

Steps to reproduce:

1. Call zephyr_get_issue_link_test_cases with issueKey set to a Jira issue that has zero linked Zephyr test cases.
2. Call it again with issueKey set to a Jira issue that has multiple (confirmed: 6) linked Zephyr test cases, verified independently via each test case's own .links.issues field (zephyr_get_test_case).
3. Both calls fail with the same error above.

Expected: An array of linked test cases (empty array for the 0-link case).

Actual: The client rejects the tool's response before it reaches the caller — the declared output schema expects an array, but the underlying response appears to be a single object instead (possibly the raw Zephyr Scale API response being passed through un-normalized when there's a non-array result shape

Impact: This tool is unusable in its current state — it fails on every issue we've tried, not just an edge case (empty result, single result, and multi-result all reproduce it).

Workaround we're using:
Reverse-lookup via zephyr_get_test_case (which works fine) — read each candidate test case's .links.issues field to find which Jira issue(s) it covers, instead of asking the issue for its linked cases directly. This requires already knowing/enumerating candidate test case keys (e.g. via zephyr_get_test_cases scoped to a folder or project), so it's a much less direct path than the broken tool would provide.

[travispollockWF]

Confirming this on 0.40.0. I think the diagnosis in the original report is slightly off in a way that matters for the fix: the Zephyr API is not returning a non-array shape. It returns a proper JSON array. The mismatch is inside this package.

Root cause

dist/zephyr/tool/issue-link/get-test-cases.js:

outputSchema: GetIssueLinkTestCases200Response,   // = zod.array(item)
...
handle = async (args) => {
  const response = await this.client.getApiClient().get(`/issuelinks/${issueKey}/testcases`);
  return {
    // requires structuredContent to be a record, not an array.
    structuredContent: { testCases: response },
    content: []
  };
};

and dist/zephyr/common/rest-api-schemas.js:

const GetIssueLinkTestCases200Response = zod.array(
  GetIssueLinkTestCases200ResponseItem
);

The handler wraps the array in an object — correctly, since MCP requires structuredContent to be a JSON object rather than an array — but outputSchema still declares a top-level array. Validation compares the wrapper object against an array schema and rejects it. The in-code comment shows the wrapping was deliberate; only the schema was left behind.

Three tools are affected, not one

Tool	Handler wraps as
zephyr_get_issue_link_test_cases	{ testCases: … }
zephyr_get_test_cycles_linked_to_a_jira_issue	{ testCycles: … }
zephyr_get_test_executions_linked_to_a_jira_issue	{ testExecutions: … }

I verified the second one reproduces identically. These are the only three Zephyr tools whose REST endpoints return a bare top-level array, which is exactly why they are the only three needing the object wrapper — and the only three whose schema was not updated to match. Every paginated tool already returns { values: [...] } and validates fine.

Version range

The identical defect is present in 0.34.0, 0.35.0, 0.39.0 and 0.40.0 (compared the published tarballs). It is input-independent, so these three tools have never worked in any of those releases.

Suggested fix

One line per tool — wrap the schema to match the handler:

const GetIssueLinkTestCases200Response = zod.strictObject({
  testCases: zod.array(GetIssueLinkTestCases200ResponseItem)
});

...and testCycles / testExecutions for the other two, matching each handler's existing wrapper key.

A more direct workaround

The REST endpoints work and return the array directly, so no candidate enumeration is needed:

GET /issuelinks/{issueKey}/testcases
GET /issuelinks/{issueKey}/testcycles
GET /issuelinks/{issueKey}/executions

Triage note

This looks distinct from #670 and #675. Those concern the outputSchema JSON Schema dialect (draft-07 vs 2020-12) being rejected client-side. This one is a plain type mismatch within the schema itself and would still fail after a dialect fix.