Rallying Scala (Metals) LSP native support in Claude Code

Tooling
1

Hi everyone,

I’d like to bring attention to a feature request I opened on the Claude Code repository: [FEATURE] Add Scala (Metals) to the native LSP plugin lineup · Issue #45132 · anthropics/claude-code · GitHub — requesting native Metals LSP integration for Scala.

Claude Code currently ships with native LSP plugins for 12+ languages, including TypeScript, Rust, Go, Python, Java (jdtls), Kotlin, C#, Ruby, PHP, Swift, Lua, and C/C++. Scala is notably absent from this list, despite Metals being a mature, well-established LSP server that follows the exact same protocol as the already-supported language servers.

Without native LSP support, Claude Code falls back to text-based search (grep) when navigating Scala codebases. This is especially painful for Scala because we have, arguably, one of the most expressive type systems out there. Implicits, extension methods, type aliases, and givens mean grep misses call sites and returns false positives constantly. Semantic intelligence via Metals would directly improve code navigation accuracy.

There are workarounds like Serena, an MCP server that wraps Metals, but its lookups introduce significant overhead.

  • Metals uses the standard LSP protocol — the same one every other supported language server uses.
  • JVM infrastructure already exists — Claude Code already supports Java (jdtls) and Kotlin (kotlin-lsp), so the JVM runtime plumbing is in place.
  • Installation is trivial — cs install metals, same as any other Coursier-based tool.
  • Implementation would be structurally identical to existing plugins.

In short, this is low-hanging fruit from an implementation standpoint, but high impact for Scala developers using AI-assisted tooling.

Urgent: the issue needs engagement

Anthropic’s bot has flagged the issue as a potential duplicate of two older, more generic requests (#24735, #24734). Hopefully this issue makes a targeted, well documented case for Metals support.

How you can help

  1. Go to the issue and thumbs-down :-1: the bot’s duplicate comment to prevent auto-closure.
  2. Thumbs-up👍 the issue itself to signal demand.
  3. Leave a comment sharing your use case — the more Scala-specific context Anthropic sees, the stronger the case.

Link: [FEATURE] Add Scala (Metals) to the native LSP plugin lineup · Issue #45132 · anthropics/claude-code · GitHub

Thanks for your time.

4 Likes
2

Thanks for looking into this! The reason why I haven’t looked into this is because I feel like dedicated MCP like the one Metals offers itself is more suited towards agents.

It’s also quite easy to setup currently either when running Metals itself with the MCP server option turned on running a standalone MCP server installable via:

cs install metals-mcp

That said, it might be worth to also mention metals LSP on the webpage to give it more exposure and to Scala overall as well. Especially, that we can push for a safer LLM code with Scala, so it’s worth putting it out there as much as possible.

4 Likes
3

I ran some benchmarks and reported my findings in this comment [FEATURE] Add Scala (Metals) to the native LSP plugin lineup · Issue #45132 · anthropics/claude-code · GitHub

In short, Metals itself is fast, the problem seems to be something related to the transport layer of Claude’s MCP. I probably misjudged Serena as well, it was probably Claude MCP all along.

In any case, querying the metals-mcp directly will be my go to option for now, I’ll just tell claude to use it that way.

1 Like
4

Was that part of the comment clowned like the rest of the Clown Code LSP “support”?

If nothing changed since last week when I’ve tried the Java integration the last time all that stuff does actually not work; it’s a complete clown show!

This nonsense just downloads another instance of the JDTLS and tries to run it without any config. Which of course fails miserably! All that while there is a fully working JDTLS already in place in the Java dev tools, but Clown Code isn’t able to use it…

This whole shit was never tested, it’s just the result of some Clown Code vibes. Of course, exactly like the whole rest of Clown Code.

Besides that LSP is a terrible protocol for LLMs. They can’t properly handle it. Whether invoked through Clown Codes “native” support or through a MCP server makes no real difference.

For proper Scala (and Java) IDE support you need a tight integration between the LSP, the BSP, and the DAP.

Nothing like that exist right now, and all the (usually vibe coded) “solutions” I found of course don’t work properly.

The first step to fix that issue would be to actually define some “natural language” “protocol” for LLMs to be able to actually use IDE tools efficiently. The real IDE protocols aren’t LLM friendly—and MCP based “solutions” need very heavyweight wrappers, which also eat a lot of tokens and context as they need very sophisticated instructions to the LLM to work more or less at all. (Which just amplifies the problem that more context isn’t necessary good as it “distracts” the models, mentioned here: [2602.11988] Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents? )

Because it’s the era of outsourcing thinking to token generators let’s just use “AI” to explain my claim that current IDE tooling is very problematic for LLMs:

https://claude.ai/share/99669d1b-323d-4507-971c-78cf7a516aaf

5

Please read what I posted in Anthropics issue as a follow up message (the part about using the LSP directly via HTTP instead of relying on Claude’s MCP client).

It works really well, actually. At least it works for me, maybe your use case is more strict/demanding.

3 Likes
6

Can it install the lsp to copilit cli too, thanks

7

Do you mean Coopilot CLI ? It should be possible after installing metals and following Adding MCP servers for GitHub Copilot CLI - GitHub Docs

Was that part of the comment clowned like the rest of the Clown Code LSP “support”?

@MateuszKowalewski While I understand the frustration when those tools don’t work and the overall state of current programming world, let’s try to stay on point and avoid loaded language. You can always just say that LSP plugins do not work for you and explain the reasons for it without venting your frustration. It doesn’t add to a constructive discussion.

9 Likes
8

Do you manage to get Claude use LSP directly instead of going through MCP?

9

Yeah, I basically just told the agent to not use his MCP tools and instead just query the lsp directly using curl.

Or actually, I mean, he uses MCP, just not through his standard tools. Wonder if one can just instruct to claude to talk LSP directly? Haven’t tried that

For exact snippets (or a very good approximate) of what I have in my AGENTS.md, I’ve set up a public repo at GitHub - NovaMage/agents-metals-direct-lsp: Just a sample file showing AGENTS.md notes so that the agent uses metals lsp without going through MCP · GitHub

It’s basically what I have minus any private projects information.

2 Likes