Metals MCP Resources vs Tools

[ckipp01]

I noticed currently that everything in the MCP server is exposed as a tool, and I'm not 100% sure that's correct. While I'm not an expert at this for sure, but looking at the various tools some of them are quite fitting as they trigger other things and have side effects, but other things are simply returning static data that seems to fit better as a resource. Taken from the docs:

Resources are a core primitive in the Model Context Protocol (MCP) that allow servers to expose data and content that can be read by clients and used as context for LLM interactions.

Wheres tools:

Tools are a powerful primitive in the Model Context Protocol (MCP) that enable servers to expose executable functionality to clients.

So for existing tools like:

• get-docs
• list-modules

These are just static information being returned that Metals knows about. Is there a reason these were implemented as tools rather than resources?

[tgodzik]

These are just static information being returned that Metals knows about. Is there a reason these were implemented as tools rather than resources?

No really, we just mostly thought of them as things that actually exist on disk as resources and need an URI, so this didn't really feel that it fits any tools we have now. I also don't see a sensible way to define the URIs.

We could do bsp://list and symbol://<semanticdb_symbol> I guess, but then we would need to encode and decode them for the latter case which could break things. It doesn't really look too great also.

[ckipp01]

I don't think there needs to be decoding/encoding both ways right? Wouldn't you only need to define the URI for the return? Like metals://build-targets?

[tgodzik]

For build targets sure, though for semanticdb it's more difficult since not all symbol characters are allowed in a URI