<details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=584258) </details> ### Summary The MCP protocol spec provides resource templates, https://modelcontextprotocol.io/specification/2025-06-18/server/resources#resource-templates The GitLab MCP Server does not implement this endpoint yet, thus causing Cline to fail on connect. ### Steps to reproduce 1. Install Cline as an extension in VS Code. 2. Open Cline and navigate to `MCP Servers` in the upper menu. 1. {width=175 height=66} 3. Select `Configure` and paste the following configuration snippet: ```json { "mcpServers": { "GitLab": { "url": "https://gitlab.com/api/v4/mcp", "type": "streamableHttp", "disabled": false, "autoApprove": [] } } } ``` 4. Authenticate against OAuth and then see the failed fetch from the GitLab MCP Server. Tests in this thread: https://gitlab.com/gitlab-org/gitlab/-/issues/561564#note_2903601641 ### Example Project ### What is the current _bug_ behavior? Cline throws an error and cannot use MCP tools at all. ### What is the expected _correct_ behavior? The URL endpoint returns an empty result, the client gracefully continues, and MCP tool calls are available for the GitLab MCP Server. ### Relevant logs and/or screenshots {width=820 height=600} ```shell Error POSTing to endpoint (HTTP 404): {"jsonrpc":"2.0","error":{"code":-32601,"message":"Method not found","data":{"method":"resources/list"}},"id":2} Error POSTing to endpoint (HTTP 404): {"jsonrpc":"2.0","error":{"code":-32601,"message":"Method not found","data":{"method":"resources/templates/list"}},"id":3} ``` ### Output of checks This bug happens on GitLab.com #### Results of GitLab environment info <details> <summary>Expand for output related to GitLab environment info</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: \`sudo gitlab-rake gitlab:env:info\`) (For installations from source run and paste the output of: \`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production\`) </pre> </details> #### Results of GitLab application Check <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:check SANITIZE=true`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`) (we will only investigate if the tests are passing) </pre> </details> ### Possible fixes I think it is fair to assume that clients expect the endpoint to exist, and are OK with an empty `resourceTemplates` array, adapted from the [docs](https://modelcontextprotocol.io/specification/2025-06-18/server/resources#resource-templates). Request ```json { "jsonrpc": "2.0", "id": 3, "method": "resources/templates/list" } ``` Response ```json { "jsonrpc": "2.0", "id": 3, "result": { "resourceTemplates": [ ] } } ``` ### How to implement A previous attempt exists in !217637 (closed without merging, now has conflicts). It is a useful reference for the approach and test coverage, but **do not reopen it** — start fresh from `master`. **What to build** Three new handler files under `lib/api/mcp/handlers/`, following the pattern of existing handlers like `lib/api/mcp/handlers/initialized_notification_request.rb`. Each handler inherits from `API::Mcp::Handlers::Base` and implements a single `invoke` method: - `list_resources.rb` — returns `{ resources: [] }` (empty array stub is sufficient for now) - `list_resource_templates.rb` — returns `{ resourceTemplates: [] }` (same) - `read_resource.rb` — optional; only needed if you want to implement actual resource reading beyond the stub **Where to wire them in** In `lib/api/mcp/base.rb`, add the new methods to `JSONRPC_METHOD_HANDLERS`: ```ruby JSONRPC_METHOD_HANDLERS = { 'initialize' => Handlers::InitializeRequest, 'notifications/initialized' => Handlers::InitializedNotificationRequest, 'resources/list' => Handlers::ListResources, 'resources/templates/list' => Handlers::ListResourceTemplates, # 'resources/read' => Handlers::ReadResource, # if implementing }.freeze ``` Also update `lib/api/mcp/handlers/initialize_request.rb` to advertise the `resources` capability in the handshake response, so clients know the server supports it: ```ruby capabilities: { tools: { listChanged: false }, resources: { subscribe: false, listChanged: false } } ``` **Feature flag** No feature flag is needed for the stub endpoints — returning empty arrays is safe and low-risk. If you implement `resources/read` (actual file content), gate it behind a `gitlab_com_derisk` flag following the pattern in `config/feature_flags/gitlab_com_derisk/mcp_toolsets.yml`. **Tests** Add request specs under `spec/requests/api/mcp/handlers/` and unit specs under `spec/lib/api/mcp/handlers/`. The closed MR !217637 contains worked examples of both that are worth reading before writing your own. ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) for information about the next patch release, including the targeted versions, expected release date, and current status. #### High-severity bug remediation To remediate high-severity issues requiring an [internal release](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads).