get_merge_requests fails with diff_refs validation error while get_merge_request works fine

Problem Summary

The get_merge_requests function fails with validation errors related to missing diff_refs fields, while get_merge_request (singular) works perfectly fine and includes the diff_refs data.

What I was doing

Testing merge request listing functionality:

// This FAILS
mcp_gitlab.get_merge_requests({
  project_id: "john/melange-mvp-template",
  per_page: 3
})

// This WORKS FINE  
mcp_gitlab.get_merge_request({
  project_id: "john/melange-mvp-template", 
  merge_request_iid: 15
})

Expected behavior

Both functions should work consistently. If get_merge_request can handle merge request objects with diff_refs data, then get_merge_requests should be able to handle arrays of the same objects.

Actual behavior

• ❌ List function fails: get_merge_requests returns validation error
• ✅ Single function works: get_merge_request returns complete data including diff_refs

Error logs

MCP error -32603: Invalid arguments: 0.diff_refs: Required, 1.diff_refs: Required, 2.diff_refs: Required

The error suggests all 3 merge requests in the response are missing required diff_refs fields.

Successful single request response

The working get_merge_request call returns:

{
  "id": 18,
  "iid": 15,
  "title": "🔒 Address Critical Security Issues from Code Review", 
  "diff_refs": {
    "base_sha": "b8c7da2df8401c8fb0c9b9c55e0036f9c111295d",
    "head_sha": "00cd266cb9342a0cc6b2dc34b52f5860462c9d1f", 
    "start_sha": "b8c7da2df8401c8fb0c9b9c55e0036f9c111295d"
  },
  // ... other fields
}

Repository tested against

• Repository: john/melange-mvp-template on git.haley.io
• Has active merge requests (confirmed via individual retrieval)
• MR #15 definitely exists and has diff_refs data

Possible root causes

1. GitLab API differences: List endpoint may not include diff_refs by default while single endpoint does
2. Schema validation mismatch: MCP server expects diff_refs in list response but GitLab doesn't provide it
3. Response processing bug: Different code paths for list vs single requests
4. Missing parameters: List endpoint may need additional parameters to include diff_refs

Impact

• Unusable list function: Cannot retrieve multiple merge requests at once
• Inconsistent API: Users confused why one function works but similar one doesn't
• Performance impact: Must make multiple single requests instead of one list request
• Feature limitation: Cannot build UIs that show MR listings

Investigation suggestions

1. Compare GitLab API responses: Check what the actual GitLab REST API returns for:

   • GET /projects/:id/merge_requests (list)
   • GET /projects/:id/merge_requests/:merge_request_iid (single)

2. Schema validation review: Check if diff_refs should be required or optional in list responses

3. Parameter options: Test if list endpoint has parameters to include diff_refs data

Workaround

Currently users must:

1. Get list of MR IIDs from another source
2. Make individual get_merge_request calls for each MR
3. Manually combine results

This is inefficient and defeats the purpose of the list function.

Suggested fixes

Option 1: Make diff_refs optional in list responses

// Allow list items to have optional diff_refs
{
  diff_refs?: {
    base_sha: string,
    head_sha: string, 
    start_sha: string
  }
}

Option 2: Add parameter to include diff_refs

// Add option to request diff_refs in list
mcp_gitlab.get_merge_requests({
  project_id: "project", 
  include_diff_refs: true
})

Option 3: Use different schema for list vs single

// List response uses minimal schema without diff_refs
// Single response uses full schema with diff_refs

Test cases for validation

// Should work without errors
mcp_gitlab.get_merge_requests({project_id: "any/project"})

// Should work with pagination  
mcp_gitlab.get_merge_requests({project_id: "any/project", per_page: 5})

// Should be consistent with single request
const list = mcp_gitlab.get_merge_requests({project_id: "project"})
const single = mcp_gitlab.get_merge_request({project_id: "project", merge_request_iid: list[0].iid})
// Both should have compatible data structures

Reproducibility

100% reproducible. The list function consistently fails while the single function consistently works on the same repository.