VSCode LM Tools Integration

[axmo]

What problem does this proposed feature solve?

At the moment LM tools provided by MCP Servers installed and managed by VSCode's UI (Command Palette - MCP: Add Server...) are not visible to Roo Code. Recent additions in the VSCode API have added the ability for Extensions to discover and invoke LM tools, which would allow us to see and use those tools.

Additionally, the VSCode Extensions API now includes methods for Extensions to register their own tools to be used by Copilot, which would become available using the same discovery and invocation mechanism.

In theory we could also register tools from Roo-manaaged MCP Servers for use by other LLM agents such as Copilot, but that is outside the scope of this feature proposal.

Describe the proposed solution in detail

This feature will enable Roo to discover and utilize language model tools that are made available by VSCode itself or other installed extensions through the vscode.lm API. The goal is to seamlessly integrate these "VSCode-Provided Tools" into Roo's existing tool ecosystem, making them accessible to Roo's Language Model (LLM).

How it should work & Key Functionalities:

1. Automatic Tool Discovery:

   • Roo will automatically detect tools registered via vscode.lm.tools when the extension starts and whenever VSCode extensions are changed (installed, uninstalled, enabled, disabled).
   • Users will not need to manually configure or add these tools to Roo.

2. Unified Tool Visibility in Roo's UI:

   • A new, virtual entry, tentatively named "VSCode Tools" (or similar), will appear in Roo's existing MCP server/tool management UI.
   • Under this "VSCode Tools" entry, users will see a list of all discovered tools from vscode.lm.tools, displaying their names and descriptions.
   • This provides a consolidated view, allowing users to see tools from Roo's own managed MCP servers alongside those provided by the broader VSCode environment.

3. LLM Access to VSCode-Provided Tools:

   • When a user interacts with Roo, the LLM will be made aware of these VSCode-Provided Tools, including their names, descriptions, and how to use them (input schemas).
   • This allows the LLM to intelligently request the use of these external tools to accomplish tasks, just as it currently does with Roo's native tools.

4. Seamless Tool Execution:

   • When the LLM decides to use a VSCode-Provided Tool, Roo will handle its execution by calling the appropriate vscode.lm.invokeTool API.
   • The user experience should be seamless; the invocation of a VSCode-Provided Tool should feel no different from invoking a tool from one of Roo's directly managed MCP servers.

User Interaction & Expected Behaviour:

• For the User:
  • Users will see an expanded list of available tools within Roo, potentially including functionalities from other extensions they have installed.
  • They don't need to do anything special to enable this; it works out of the box.
  • The primary interaction is indirect: the LLM will leverage these tools on the user's behalf to provide better assistance.
• For the LLM:
  • The LLM gains access to a richer set of capabilities, allowing it to perform more complex tasks or provide more accurate information by leveraging specialized tools from the VSCode ecosystem.
• Expected Behaviour:
  • Roo remains stable and performant even with a large number of VSCode-Provided Tools.
  • Tool invocation is reliable.
  • Clear distinction in the UI between Roo-managed tools and VSCode-Provided Tools (e.g., via the "VSCode Tools" virtual server grouping).

Technical considerations or implementation details (optional)

Integrate Roo with VSCode's vscode.lm API to discover and utilize tools provided by VSCode and other extensions. This feature will focus solely on consuming tools listed in vscode.lm.tools.

Key Components of the Solution:

1. New VSCodeLmIntegration.ts Class:

   • This new, lean class will be responsible for all direct interactions with the vscode.lm namespace.
   • Tool Discovery: It will fetch the list of available tools from vscode.lm.tools upon initialization and monitor for changes (e.g., via vscode.extensions.onDidChange).
   • Tool Invocation: It will provide a method to execute these discovered tools using vscode.lm.invokeTool(name, options, token).
   • It will emit an event (e.g., onDidChangeVSCodeProvidedTools) to notify other parts of Roo (like McpHub) about the available VSCode-provided tools.

2. Updates to McpHub.ts:

   • McpHub will subscribe to VSCodeLmIntegration.onDidChangeVSCodeProvidedTools.
   • It will create and manage a virtual "VSCode-Provided Tools" server entry in its list of servers.
     • This virtual server will have a distinct name (e.g., "VSCode Tools") and source (e.g., "vscode-lm").
     • Its tools list will be populated by transforming LanguageModelToolInformation objects (from vscode.lm.tools) into Roo's McpTool (or a compatible) structure, including name, description, and inputSchema.
   • McpHub will include this virtual server and its tools when notifying the webview UI (notifyWebviewOfServerChanges).
   • The McpHub.callTool (or equivalent) method will be updated:
     • If a requested tool is found on a Roo-managed server, it will be invoked via the MCP SDK as usual.
     • If not, and the tool is found under the "VSCode-Provided Tools" virtual server, McpHub will delegate the call to VSCodeLmIntegration.invokeVSCodeTool().

3. UI Representation:

   • The Roo UI (webview) will display the "VSCode-Provided Tools" as a distinct (virtual) server in the MCP server list.
   • Users will be able to see the tools available from vscode.lm.tools alongside Roo's directly managed MCP server tools.

4. LLM Context:

   • Roo's LLM context builder will be updated to include information (name, description, input schema) about these VSCode-Provided Tools, making them available for the LLM to request.

This solution allows Roo to leverage the existing VSCode tool ecosystem, enhancing its capabilities without needing to manage the lifecycle of the servers providing these tools (as VSCode handles that).

Describe alternatives considered (if any)

1. Full VSCode MCP Server Integration (Discovery & Management):

   • Description: The initial plan was to deeply integrate with vscode.lm to discover, monitor status, and manage the lifecycle of MCP servers defined by VSCode or other extensions.
   • Reason for not choosing: The necessary vscode.lm APIs for server discovery are not available in the current VSCode type definitions. This makes direct server-level integration unfeasible through official APIs.

2. Relying on Reading VSCode's Internal Configuration Files for Tool Discovery:

   • Description: An earlier iteration attempted to discover servers and their capabilities by directly parsing VSCode's settings.json (mcp.servers, mcp.serverCapabilities, etc.) and .vscode/mcp.json.
   • Reason for not choosing for primary tool discovery: This approach is brittle as it relies on internal VSCode configuration structures that are not guaranteed to be stable or part of a public API. While it might be considered for an optional "import server config" feature in the future, vscode.lm.tools is the official and more robust way to discover tools available to the language model.

3. No Integration:

   • Description: Continue with Roo only managing its own MCP servers and tools.
   • Reason for not choosing: This misses the opportunity to leverage the broader VSCode tool ecosystem, potentially limiting Roo's LLM capabilities and leading to redundant tool development.

Additional Context & Mockups

No response

Proposal Checklist

• I have searched existing Issues and Discussions to ensure this proposal is not a duplicate.
• This proposal is for a specific, actionable change intended for implementation (not a general idea).
• I understand that this proposal requires review and approval before any development work begins.

Are you interested in implementing this feature if approved?

• Yes, I would like to contribute to implementing this feature.

[complyue]

Hi @axmo ! I would join your efforts to make this proposal.

Here is some info from changelog.md of github.copilot-chat-0.27.2 for discussion:

Any tool contributed to this API which sets toolReferenceName and canBeReferencedInPrompt in its configuration is automatically available in agent mode.

I struggled to have tools from https://github.com/complyue/Roo-NB appear in Copilot's tool list, and finally found it's essential to have toolReferenceName defined in package.json.

It means Copilot not merely scans vscode.lm.tools, but also scans all contributing extensions' package.json. ref: https://code.visualstudio.com/api/extension-guides/tools#create-a-language-model-tool

I like it that way, LanguageModelToolInformation.description may come from modelDescription in package.json, and there is userDescription to show in i18n UI.

A sample from package.json of github.copilot-chat-0.27.2 :

	"contributes": {
		"languageModelTools": [
			{
				"name": "copilot_searchCodebase",
				"toolReferenceName": "codebase",
				"displayName": "%copilot.tools.searchCodebase.name%",
				"icon": "$(folder)",
				"canBeReferencedInPrompt": true,
				"userDescription": "%copilot.codebase.tool.description%",
				"modelDescription": "Run a natural language search for relevant code or documentation comments from the user's current workspace. Returns relevant code snippets from the user's current workspace if it is large, or the full contents of the workspace if it is small.",
				"tags": [
					"codesearch",
					"vscode_editing",
					"vscode_codesearch"
				],
				"inputSchema": {
					"type": "object",
					"properties": {
						"query": {
							"type": "string",
							"description": "The query to search the codebase for. Should contain all relevant context. Should ideally be text that might appear in the codebase, such as function names, variable names, or comments."
						}
					},
					"required": [
						"query"
					]
				}
			},

[complyue]

@axmo are you drafting any part of the implementation?

I'm tempted to do some tech PoC by adding to Roo some minimal UI like Copilot's Select Tools button, and make those extension-contributed tools usable by Roo, maybe you've done this part?

[axmo]

I have a couple of partial implementations of getting Roo to see VSCode-installed MCP servers in old branches, but main has diverged from them significantly at this point... Also they are from before vscode.lm.tools and invokeTool became available.

I have not started on an implementation for this proposal at all. (Due to lack of time, as well as waiting for the issue to be approved and added to roadmap, before I start work on it)

[hannesrudolph]

Thanks for submitting this proposal. However, as it currently stands, the scope and problem statement are quite broad, making it difficult to evaluate clearly or provide precise feedback. A significant architectural integration like this requires a narrower, well-defined use case and solution to ensure alignment with our roadmap and development resources.

Please create a new detailed feature proposal focused on a specific, clearly-defined use case and corresponding targeted solution. Narrowing the scope will help the development team evaluate and approve the feature more easily, reduce the risk of extensive rebasing, and avoid significant rework later due to misunderstandings or differing expectations around the implementation.