為 GitLab 與 MCP 作上游開源工程貢獻：一週工作的經驗

Over the past sprint, I contributed a series of upstream enhancements and bug fixes to GitLab (gitlab-org/gitlab) and the GitLab Language Server (gitlab-org/editor-extensions/gitlab-lsp).

Most of these changes focus on GitLab’s implementation of the Model Context Protocol (MCP)—the protocol connecting AI agents and IDE assistants (like GitLab Duo) to GitLab's API—as well as race-condition resilience in Language Server protocols.

Here is a comprehensive retrospective on what was built, the architectural decisions behind them, and lessons learned getting complex merge requests to 100% green pipelines under GitLab's rigorous review standards.

1. Enabling Note Editing in the MCP save_note Tool (!264854)

The Challenge

The MCP save_note tool allowed AI agents to post comments, reply to discussion threads, and resolve discussions on merge requests and work items. However, agents could not edit their existing comments or refine feedback in-place, leading to comment sprawl.

The Solution

We introduced the update_note method to save_note:

• GraphQL Mutation Integration: Leveraged Mutations::Notes::Update::Base (updateNote) with proper authorization checks and quick-action guards.
• Flexible Note ID Normalization: Agents might supply a bare integer ID (from review tools) or a full Global ID (gid://gitlab/Note/123). We updated the tool schema to accept oneOf: [{ type: 'string' }, { type: 'integer' }] and automatically coerce them.
• Container Governance for Group-Level Items: Group-level work items and epics don't have a project, so we ensured the governance container resolver properly fell back to note.namespace to enforce project/group tool policies.
• Ruby false.blank? Trap: In Ruby/Rails, false.blank? evaluates to true. When validating method arguments for boolean fields like resolved: false, a naive .blank? check erroneously flagged the parameter as missing. We implemented strict string-blankness checking (val.nil? || (val.is_a?(String) && val.blank?)) to guarantee boolean stability.

2. Exposing User Contribution Events to MCP with JSON Schema Compatibility (!264864)

The Challenge

Agents needed visibility into recent user activity to assist with sprint summaries and standups. While /users/:id/events existed as a REST endpoint, it was not exposed as an MCP tool.

The Solution

• API Tool Exposure: Bound the endpoint as list_user_events in the :core toolset with pagination, action, and target-type filters.
• Date Type Schema Fix (ApiTool::TYPE_CONVERSIONS): Grape defines parameters like before and after with type: Date. Grape's MCP tool mapper previously lacked a mapping for Date, emitting "type": "date" in the generated JSON Schema—which is invalid according to the JSON Schema meta-schema and caused strict MCP clients to reject the tool catalog. We added 'Date' => 'string' to map dates cleanly to ISO 8601 strings.
• Handbook Documentation: Documented the tool, parameters, and history blocks in mcp_server_tools.md.

3. Consolidating Pipeline Creation into save_pipeline (!264858)

The Challenge

An earlier draft introduced a separate tool to create merge request pipelines. Reviewers pointed out that having both save_pipeline and a dedicated merge request pipeline tool introduced fragmentation and API redundancy.

The Solution

• Single Responsibility Principle: Consolidated the merge request trigger directly into SavePipelineService using an optional merge_request_iid parameter.
• Zero-Route Redundancy: Reverted unnecessary Grape route settings and handled project/pipeline discovery within the core service.
• RuboCop Layout Compliance: Aligned multiline exception rescue blocks to satisfy GitLab's strict rubocop layout rules.

4. Work Item Parent Filtering & MCP Validation Ergonomics (!264859 & !264853)

Work Item Parent Filtering (!264859)

• Added parent_iid support to the list_work_items MCP tool, enabling agents to query tasks and child items belonging to a specific parent issue or epic.
• Added comprehensive unit specs and documentation updates.

Informative MCP Validation Errors (!264853)

• When LLMs make tool calls with misspelled or extraneous arguments, generic error messages force them into trial-and-error loops.
• Refactored argument validation to explicitly return both the unknown parameters and the list of accepted parameters, allowing AI models to self-correct in a single turn.
• Verified across all 3,000+ MCP tool specs with zero regressions.

5. Eliminating Cross-Session Message Leaks in gitlab-lsp (!4539)

The Challenge

In the GitLab Language Server (gitlab-lsp), when a user ran /new to initiate a clean session while pending wake messages were queued, old microtasks could resolve and dispatch messages to the newly instantiated session, causing stale state corruption.

The Solution

• Wrapped pending wake operations with session IDs and implemented await flushMicrotasks() during session teardown.
• Added automated mid-stream cancellation tests to ensure pending events from defunct sessions are deterministically discarded.
• Achieved a 100% green CI pipeline across all 82 jobs.

Key Takeaways for Contributing to Large-Scale Projects

1. Beware of Truthiness Edge-Cases: In Rails, remember that false.blank? == true. Always check .nil? or type-check when accepting booleans.
2. Adhere to the Rule of Minimum Code: If a capability can be cleanly folded into an existing tool or service (like adding merge_request_iid to save_pipeline), do that instead of spawning new classes.
3. Strict JSON Schema Compliance Matters: LLM tool runners and protocol clients parse schemas strictly. Non-standard types like "date" will break tool discovery across ecosystems.
4. Resilient CI Habits: Multi-stage CI pipelines test everything from Danger rules to Pajamas component adoption. Running linters locally and writing isolated unit specs keeps reviews moving fast.

All Merge Requests linked above are open or merged in GitLab's official repositories. Happy hacking!