Add Experimental MCP Support

[st0012]

Add Model Context Protocol (MCP) support to Ruby LSP

This PR adds support for the Model Context Protocol (MCP), enabling AI assistants to programmatically access Ruby project indexes and file contents that Ruby LSP already collects.

Connection Mechanism

The implementation uses a hybrid approach:

1. Ruby LSP runs an HTTP-based MCP server powered by WEBrick on a dynamically assigned local port
2. A lightweight stdio-to-HTTP bridge script (ruby-mcp-bridge) connects the editor's MCP client to our HTTP server
3. Communication flows bidirectionally between AI assistants and the Ruby project's metadata

Architecture Diagram

Editor Setup

VS Code Configuration

Add to .vscode/mcp.json:

{
  "inputs": [],
  "servers": {
    "rubyMcp": {
      "type": "stdio",
      "command": "${workspaceFolder}/.ruby-lsp/ruby-mcp-bridge"
    }
  }
}

See VS Code MCP documentation for more details.

Cursor Configuration

Add to .cursor/mcp.json:

{
  "mcpServers": {
    "rubyMcp": {
      "command": "./.ruby-lsp/ruby-mcp-bridge"
    }
  }
}

See Cursor MCP documentation for more details.

Notes For Manual Testing

This feature requires both the extension and server changes to work. So for testing:

1. Run the extension with the subject project
2. Update the subject project's Gemfile to have gem "ruby-lsp", github: "Shopify/ruby-lsp", branch: "mcp"
3. Make sure the server is connected to the respective editors. When connected, the editor should display what tools are available
4. In both editors, MCP servers are only used in "Agent" mode
5. For VS Code, tool usage needs to be selected manually at each prompt

Known Issues

⚠️ Cursor-specific issue: We've identified that Cursor's MCP/LSP client implementation can occasionally cause hangs in the Ruby LSP process. The main thread gets stuck waiting on gets in the LSP communication channel. This issue may be specific to Cursor as it doesn't occur (or occurs much less frequently) in VS Code, and more often in certain projects (e.g. ruby/irb) than others. The cause may be related to how Cursor handles MCP/LSP requests and requires more investigation.

Supported Tools (TBD)

The MCP server provides four tools:

1. get_classes_and_modules - Browse all indexed classes and modules in your project, with optional query filtering
2. read_ruby_files - Access file contents, including from dependencies
   • I removed this because clients usually would ask additional permission to read files outside of the workspace, and Ruby MCP should not provide a way to get around that.
3. get_methods_details - Get comprehensive information about methods (documentation, parameters, location, visibility)
4. get_class_module_details - See class/module details including documentation, ancestry chains, and available methods

These tools enable AI assistants to understand Ruby code structure, navigate dependencies, and access relevant documentation that are not accessible through the editor's simple codebase indexing.

[graphite-app]

How to use the Graphite Merge Queue

Add the label graphite-merge to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

[andyw8]

Some early notes on how to try this with Zed:

• Check out this branch locally (as a small modification is needed) and point your project's Gemfile to it.

• Manually copy ruby-mcp-bridge into .ruby-lsp in your project (ensure it retains the +x permission) since we can't rely on the VS Code extension (a Zed extension should be fairly easy though).

• Configure the project settings:

  // .zed/settings.json
  {
    "context_servers": {
      "mcp-servers-ruby-lsp": {
        "command": {
          "path": "/path/to/project/.ruby-lsp/ruby-mcp-bridge", // seems to need an absolute path
          "args": []
        },
      }
    }

Modify global_state.rb in Ruby LSP to make it Zed-aware:

def detects_ruby_mcp
  check_mcp_file(".vscode/mcp.json", ["servers", "rubyMcp"]) ||
    check_mcp_file(".cursor/mcp.json", ["mcpServers", "rubyMcp"]) ||
    check_mcp_file(".zed/settings.json", ["context_servers", "mcp-servers-ruby-lsp"])
end

Reload Zed, choose Tools in the Agent panel and if all well you should see get_classes_and_modules etc. listed:

[st0012]

We decided not to continue with this approach because we identified a few challenges:

• LSP & MCP have very different expectations on servers' lifecycle and numbers of connections per client application:
  • A local MCP server nowadays usually last as long as the client's connection to it. But a LSP server, especially Ruby LSP, can restart multiple times in the same editor session (e.g. updating bundle or rebasing...etc.)
  • An editor usually only has 1 MCP client but can have multiple LSP clients (in a multi-workspace setup)
• Since LSP servers are connected through stdio of the process, to connect to a MCP client too the server needs to either use a unix or tcp/ip socket, which adds a lot of complexity
• While using http for connection is also possible, it requires adding a http server library to the project, which we want to avoid

And so far we don't see a solution that can overcome all the challenges while providing a easy, robust experience to users. It also won't work for non-editor clients like Claude Code. So after some discussions, we decided that it's not worth continuing the type of integration with LLMs.

That said, an alternative could be to use VS Code's LLM tooling API that directly requests information through Ruby LSP's custom server requests. It'll be a much simpler solution but will only work for VS Code (until Cursor supports the same APIs).

[kuboon]

I've tried this with ruby-lsp but it seems fails.
https://github.com/mizchi/lsmcp