[ENHANCEMENT] Expose more powerful VS Code language-analysis APIs as tools for the Roo Code LLM

[tinyvan]

Problem (one or two sentences)

Roo Code's LLM has great access to basic file read/write/edit operations, but it lacks tools to use powerful built-in VS Code language features like find references, go to definition, workspace-wide symbol search, call hierarchy, and others. This limits how deeply and accurately the agent can understand and reason about large codebases.

Context (who is affected and when)

The Roo Code LLM should be able to call additional high-value VS Code commands as tools — the same way it can already read/write files — so it can ask the editor for definitions, references, symbols across the workspace, call hierarchies, incoming/outgoing calls, etc. This would let the agent truly understand project structure and give much smarter, more precise answers and code changes.

Desired behavior (conceptual, not technical)

• These calls should be fast and lightweight when possible (most are already very efficient in VS Code).
• Return only the necessary information (e.g. locations, symbol names, short previews) to keep context size reasonable.
• Prefer simple, clear tool schemas (e.g. uri + position → list of locations or symbols).
• No breaking changes to existing tools/behavior.

Constraints / preferences (optional)

No response

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Roo Code Task Links (optional)

No response

Acceptance criteria (optional)

Given a user asks Roo Code something like "where is processPayment used across the project?"
When the agent needs to answer
Then it can call a tool (e.g. executeReferenceProvider) and correctly list files/locations where the symbol is referenced

    Given a user says "show me the call hierarchy for authenticateUser"
    When the agent analyzes impact
    Then it can use prepareCallHierarchy + outgoing/incoming calls tools to build and describe the call graph

    Given a user asks "find me the definition of UserService"
    When the agent navigates code
    Then it can use executeDefinitionProvider and jump to (or describe) the correct location

    And the tool responses are returned in a format that's easy for the LLM to parse and reason over
    But unnecessary large ASTs or full file contents are not included unless requested

Proposed approach (optional)

Add new tool functions that wrap these VS Code API commands (available via vscode.commands.executeCommand):

    - vscode.executeWorkspaceSymbolProvider(query)
    - vscode.executeReferenceProvider(uri, position)
    - vscode.executeDefinitionProvider(uri, position)
    - vscode.executeDocumentSymbolProvider(uri)
    - vscode.prepareCallHierarchy(uri, position)
    - CallHierarchyItem.provideOutgoingCalls()
    - CallHierarchyItem.provideIncomingCalls()

    Start with the most commonly useful ones: references, definitions, workspace symbols, and document symbols.

    Return clean JSON-like structures (locations as {uri, range}, symbols with name/kind/location, etc.) to keep token usage low.

Trade-offs / risks (optional)

• Some calls (especially workspace-wide) can be slow on very large projects → consider optional limits or pagination.
• Slightly larger context size if many locations are returned → the LLM can be instructed to ask for summaries or focus on specific files.
• Dependency on language server quality — but that's already true for VS Code itself.

[roomote-v0]

I've analyzed this issue and the existing tool architecture in detail. Here's my proposed implementation plan:

Proposed Implementation Plan

Overview

Add a new set of VS Code language analysis tools that wrap built-in VS Code language server APIs (vscode.commands.executeCommand). These tools will let the LLM query definitions, references, symbols, and call hierarchies directly from the editor's language server.

New Tools (Phase 1 - Most Commonly Useful)

1. go_to_definition - Wraps vscode.executeDefinitionProvider(uri, position) - Returns definition location(s) for a symbol at a given file/line/character position
2. find_references - Wraps vscode.executeReferenceProvider(uri, position) - Returns all reference locations for a symbol
3. workspace_symbols - Wraps vscode.executeWorkspaceSymbolProvider(query) - Searches for symbols across the entire workspace by name
4. document_symbols - Wraps vscode.executeDocumentSymbolProvider(uri) - Lists all symbols in a specific file (functions, classes, variables, etc.)

Future Phase (Can be added later)

5. call_hierarchy - Wraps vscode.prepareCallHierarchy + incoming/outgoing calls - Builds call graphs for a given function

Files to Create/Modify

For each new tool, following the existing patterns:

1. Type Registration (packages/types/src/tool.ts)

• Add "go_to_definition", "find_references", "workspace_symbols", "document_symbols" to the toolNames array

2. Tool Group Registration (src/shared/tools.ts)

• Add the new tools to the "read" tool group (since these are read-only analysis operations)
• Add entries to TOOL_DISPLAY_NAMES
• Add NativeToolArgs type definitions for each tool
• Add ToolUse interfaces for each tool
• Add entries to toolParamNames as needed

3. Native Tool Definitions (one file each in src/core/prompts/tools/native-tools/)

• go_to_definition.ts - OpenAI tool schema: params { path, line, character }
• find_references.ts - OpenAI tool schema: params { path, line, character }
• workspace_symbols.ts - OpenAI tool schema: params { query }
• document_symbols.ts - OpenAI tool schema: params { path }
• Register all in src/core/prompts/tools/native-tools/index.ts

4. Tool Implementations (one file each in src/core/tools/)

• GoToDefinitionTool.ts - Extends BaseTool, calls vscode.commands.executeCommand("vscode.executeDefinitionProvider", uri, position), formats result as compact JSON locations
• FindReferencesTool.ts - Similar pattern, calls vscode.executeReferenceProvider
• WorkspaceSymbolsTool.ts - Calls vscode.executeWorkspaceSymbolProvider, returns {name, kind, location} objects
• DocumentSymbolsTool.ts - Calls vscode.executeDocumentSymbolProvider, returns symbol tree

5. Tool Routing (src/core/assistant-message/presentAssistantMessage.ts)

• Import and wire up each new tool singleton in the main tool dispatch switch

6. Tool Validation (src/core/tools/validateToolUse.ts)

• Register the new tool names as valid

Response Format

All tools will return clean, compact JSON to minimize token usage:

// go_to_definition / find_references
[{ "path": "src/auth.ts", "line": 42, "character": 10 }]

// workspace_symbols
[{ "name": "UserService", "kind": "Class", "path": "src/services/user.ts", "line": 5 }]

// document_symbols  
[{ "name": "processPayment", "kind": "Function", "line": 12, "endLine": 45 }]

Safeguards

• Result limits: Cap returned results (e.g., max 50 references, 100 symbols) to avoid context overflow
• Graceful degradation: Return informative messages when no language server is available for a file type
• No breaking changes: These are purely additive new tools in the existing read group

Tests

• Unit tests for each tool implementation in src/core/tools/__tests__/
• Tests for native tool definitions in src/core/prompts/tools/native-tools/__tests__/

This approach follows the exact same patterns used by existing tools (e.g., ReadFileTool, ListFilesTool, SearchFilesTool) and should integrate cleanly.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[tinyvan]

@roomote youare so cool ai! can you make it?

[roomote-v0]

Hey @tinyvan! I've seen your comment and will take a crack at implementing the VS Code language-analysis tools described in the plan above. I'll open a draft PR to share progress shortly.

[roomote-v0]

Opened a draft PR with my attempt at implementing the Phase 1 language-analysis tools (go_to_definition, find_references, workspace_symbols, document_symbols): #11904

All tests and type checks pass. Feedback welcome!