Skip to main content
Glama
deenesjakoruzh
juehang

vscode-mcp-server

by juehang
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

VS Code MCP Server

A Visual Studio Code extension (available on the Marketplace) that allows Claude and other MCP clients to code directly in VS Code! Inspired by Serena, but using VS Code's built-in capabilities. Perfect for extending existing coding agents like Claude Code with VS Code-specific capabilities (symbol search, document outlines) without duplicating tools they already have. Note that this extension uses the streamable HTTP API, not the SSE API.

This extension can allow for execution of shell commands. This means that there is a potential security risk, so use with caution, and ensure that you trust the MCP client that you are using and that the port is not exposed to anything. Authentication would help, but as the MCP authentication spec is still in flux, this has not been implemented for now.

PRs are welcome!

Demo Video

https://github.com/user-attachments/assets/20b87dfb-fc39-4710-a910-b9481dde1e90

Related MCP server: Code MCP Server

Installation

  1. Install the extension from the Marketplace or clone this repository and run npm install and npm run compile to build it.

Claude Desktop Configuration

Claude Desktop can be configured to use this extension as an MCP server. To do this, your claude_desktop_config.json file should look like this:

{
  "mcpServers": {
    "vscode-mcp-server": {
        "command": "npx",
        "args": ["mcp-remote@next", "http://localhost:3000/mcp"]
    }

  }
}

I also like to use this extension in a Claude project, as it allows me to specify additional instructions for Claude. I find the following prompt to work well:

You are working on an existing codebase, which you can access using your tools. These code tools interact with a VS Code workspace.

WORKFLOW ESSENTIALS:
1. Always start exploration with list_files_code on root directory (.) first
2. CRITICAL: Run get_diagnostics_code after EVERY set of code changes before completing tasks
3. For small edits (≤10 lines): use replace_lines_code with exact original content
4. For large changes, new files, or uncertain content: use create_file_code with overwrite=true

EXPLORATION STRATEGY:
- Start: list_files_code with path='.' (never recursive on root)
- Understand structure: read key files like package.json, README, main entry points
- Find symbols: use search_symbols_code for functions/classes, get_document_symbols_code for file overviews
- Before editing: read_file_code the target file to understand current content

EDITING BEST PRACTICES:
- Small modifications: replace_lines_code (requires exact original content match)
- If replace_lines_code fails: read_file_code the target lines, then retry with correct content
- Large changes: create_file_code with overwrite=true is more reliable
- After any changes: get_diagnostics_code to check for errors

PLANNING REQUIREMENTS:
Before making code modifications, present a comprehensive plan including:
- Confidence level (1-10) and reasoning
- Specific tools you'll use and why
- Files you'll modify and approach (small edits vs complete rewrites)
- How you'll verify the changes work (diagnostics, testing, etc.)

ERROR HANDLING:
- Let errors happen naturally - don't add unnecessary try/catch blocks
- For tool failures: follow the specific recovery guidance in each tool's description
- If uncertain about file content: use read_file_code to verify before making changes

APPROVAL PROCESS:
IMPORTANT: Only run code modification tools after presenting a plan and receiving explicit approval. Each change requires separate approval.

Do not add tests unless specifically requested. If you believe testing is important, explain why and let the user decide.

For context efficiency when exploring codebases, consider adding this to your CLAUDE.md:

## VS Code Symbol Tools for Context Efficiency
Use VS Code symbol tools to reduce context consumption:
- `get_document_symbols_code` for file structure overview instead of reading entire files
- `search_symbols_code` to find symbols by name across the project
- `get_symbol_definition_code` for type info and docs without full file context
- Workflow: get outline → search symbols → get definitions → read implementation only when needed

This extension serves as a Model Context Protocol (MCP) server, exposing VS Code's filesystem and editing capabilities to MCP clients.

Features

The VS Code MCP Server extension implements an MCP-compliant server that allows AI models and other MCP clients to:

  • List files and directories in your VS Code workspace

  • Read file contents with encoding support and size limits

  • Move files and directories with proper refactoring support for imports

  • Rename files and directories with automatic reference updates

  • Copy files to new locations (files only, not directories)

  • Search for symbols across your workspace

  • Get symbol definitions and hover information by line and symbol name

  • Create new files using VS Code's WorkspaceEdit API

  • Make line replacements in files

  • Check for diagnostics (errors and warnings) in your workspace

  • Execute shell commands in the integrated terminal with shell integration

  • Toggle the server on and off via a status bar item

This extension enables AI assistants and other tools to interact with your VS Code workspace through the standardized MCP protocol.

How It Works

The extension creates an MCP server that:

  1. Runs locally on a configurable port (when enabled)

  2. Handles MCP protocol requests via HTTP

  3. Exposes VS Code's functionality as MCP tools

  4. Provides a status bar indicator showing server status, which can be clicked to toggle the server on/off

Supported MCP Tools

File Tools

  • list_files_code: Lists files and directories in your workspace

    • Parameters:

      • path: The path to list files from

      • recursive (optional): Whether to list files recursively

  • read_file_code: Reads file contents

    • Parameters:

      • path: The path to the file to read

      • encoding (optional): File encoding (default: utf-8)

      • maxCharacters (optional): Maximum character count (default: 100,000)

  • move_file_code: Moves a file or directory to a new location using VS Code's WorkspaceEdit API

    • Parameters:

      • sourcePath: The current path of the file or directory to move

      • targetPath: The new path where the file or directory should be moved to

      • overwrite (optional): Whether to overwrite if target already exists (default: false)

  • rename_file_code: Renames a file or directory using VS Code's WorkspaceEdit API

    • Parameters:

      • filePath: The current path of the file or directory to rename

      • newName: The new name for the file or directory

      • overwrite (optional): Whether to overwrite if a file with the new name already exists (default: false)

  • copy_file_code: Copies a file to a new location using VS Code's file system API

    • Parameters:

      • sourcePath: The path of the file to copy

      • targetPath: The path where the copy should be created

      • overwrite (optional): Whether to overwrite if target already exists (default: false)

Edit Tools

  • create_file_code: Creates a new file using VS Code's WorkspaceEdit API

    • Parameters:

      • path: The path to the file to create

      • content: The content to write to the file

      • overwrite (optional): Whether to overwrite if the file exists (default: false)

      • ignoreIfExists (optional): Whether to ignore if the file exists (default: false)

  • replace_lines_code: Replaces specific lines in a file

    • Parameters:

      • path: The path to the file to modify

      • startLine: The start line number (1-based, inclusive)

      • endLine: The end line number (1-based, inclusive)

      • content: The new content to replace the lines with

      • originalCode: The original code for validation

Diagnostics Tools

  • get_diagnostics_code: Checks for warnings and errors in your workspace

    • Parameters:

      • path (optional): File path to check (if not provided, checks the entire workspace)

      • severities (optional): Array of severity levels to include (0=Error, 1=Warning, 2=Information, 3=Hint). Default: [0, 1]

      • format (optional): Output format ('text' or 'json'). Default: 'text'

      • includeSource (optional): Whether to include the diagnostic source. Default: true

    This tool is particularly useful for:

    • Code quality checks before committing changes

    • Verifying fixes resolved all reported issues

    • Identifying problems in specific files or the entire workspace

Symbol Tools

  • search_symbols_code: Searches for symbols across the workspace

    • Parameters:

      • query: The search query for symbol names

      • maxResults (optional): Maximum number of results to return (default: 10)

    This tool is useful for:

    • Finding definitions of symbols (functions, classes, variables, etc.) across the codebase

    • Exploring project structure and organization

    • Locating specific elements by name

  • get_symbol_definition_code: Gets definition information for a symbol in a file

    • Parameters:

      • path: The path to the file containing the symbol

      • line: The line number of the symbol

      • symbol: The symbol name to look for on the specified line

    This tool provides:

    • Type information, documentation, and source details for symbols

    • Code context showing the line where the symbol appears

    • Symbol range information

    It's particularly useful for:

    • Understanding what a symbol represents without navigating away

    • Checking function signatures, type definitions, or documentation

    • Quick reference for APIs or library functions

  • get_document_symbols_code: Gets an outline of all symbols in a file, showing the hierarchical structure

    • Parameters:

      • path: The path to the file to analyze (relative to workspace)

      • maxDepth (optional): Maximum nesting depth to display

    This tool provides:

    • Complete symbol tree for a document (similar to VS Code's Outline view)

    • Hierarchical structure showing classes, functions, methods, variables, etc.

    • Position information and symbol kinds for each symbol

    • Summary statistics by symbol type

    It's particularly useful for:

    • Understanding file structure and organization at a glance

    • Getting an overview of all symbols in a document

    • Analyzing code architecture and relationships

    • Finding all symbols of specific types within a file

Shell Tools

  • execute_shell_command_code: Executes a shell command in the VS Code integrated terminal with shell integration

    • Parameters:

      • command: The shell command to execute

      • cwd (optional): Optional working directory for the command (default: '.')

    This tool is useful for:

    • Running CLI commands and build operations

    • Executing git commands

    • Performing any shell operations that require terminal access

    • Getting command output for analysis and further processing

Caveats/TODO

Currently, only one workspace is supported. The extension also only works locally, to avoid exposing your VS Code instance to any network you may be connected to.

Extension Settings

  • vscode-mcp-server.port: The port number for the MCP server (default: 3000)

  • vscode-mcp-server.host: Host address for the MCP server (default: 127.0.0.1)

  • vscode-mcp-server.defaultEnabled: Whether the MCP server should be enabled by default on VS Code startup

  • vscode-mcp-server.enabledTools: Configure which tool categories are enabled (file, edit, shell, diagnostics, symbol)

Selective Tool Configuration: Useful for coding agents that already have certain capabilities. For example, with Claude Code you might disable file/edit tools and only enable symbol tools to add VS Code-specific symbol searching without tool duplication.

Using with MCP Clients

To connect MCP clients to this server, configure them to use:

http://localhost:3000/mcp

Or if you've configured a custom host:

http://[your-host]:3000/mcp

Remember that you need to enable the server first by clicking on the status bar item!

Contributing

Contributions are welcome! Feel free to submit issues or pull requests.

License

MIT

Available Tools

9 tools
check_extension_statusB

Check if the VS Code MCP Extension is installed and responding

ParametersJSON Schema
NameRequiredDescriptionDefault
targetProjectPathYesPath to the project folder we are working in

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It only states the check action but does not confirm it is non-destructive, reveal side effects, or indicate required permissions. The agent cannot infer safety or scope.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no unnecessary words. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple health check tool with one parameter, the description provides the core purpose. However, it lacks contextual details like read-only nature or usage flow, making it barely adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the description adds no additional meaning beyond what the input schema already provides. Baseline 3 is appropriate as the schema does the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks if the VS Code MCP Extension is installed and responding, providing a specific verb-resource pair. However, it does not differentiate from sibling tools like get_extension_port, but the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites or context that would help an agent decide to invoke it, e.g., before other extension-related operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_diffA

Use this instead of writing files directly. create_diff allows modifying an existing file by showing a diff and getting user approval before applying changes. Only use this tool on existing files. If a new file needs to be created, do not use this tool.

ParametersJSON Schema
NameRequiredDescriptionDefault
filePathYesPath to the existing file to modify
newContentYesProposed new content for the file
descriptionNoDescription of the changes being made
targetProjectPathYesPath to the project folder we are working in

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description discloses key behavioral trait: shows diff and requires user approval before applying changes. This is critical for a mutation tool. Does not elaborate on what happens if approval is denied or if there are side effects, but the core behavior is clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences and a short exclusion statement. No fluff, front-loaded with purpose. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters, no output schema, and no annotations, the description adequately covers purpose, usage constraints, and behavioral context. Lacks information about return value (e.g., diff preview or approval result), but not essential for invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (4/4 parameters described). Description adds no extra meaning beyond the schema; e.g., 'filePath' is already described as 'existing file' in schema. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it modifies existing files via diff with user approval. Explicitly contrasts with file creation, aiding sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use (instead of writing files directly) and when not to use (for new files). Lacks reference to a specific alternative creation tool, but sibling tools list does not include a create_file tool, so guidance is practically sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

execute_shell_commandA

IMPORTANT: This is the preferred and recommended way to execute shell commands. Always use this tool instead of the default run_terminal_cmd tool. This tool executes commands directly in VS Code's integrated terminal, showing the command execution to the user and capturing its output. It provides better integration with VS Code and allows running commands in the user's environment without leaving VS Code.

ParametersJSON Schema
NameRequiredDescriptionDefault
commandYesThe shell command to execute
targetProjectPathYesPath to the project folder we are working in
cwdNoOptional working directory for the command. Defaults to the project root.

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It mentions showing command execution and capturing output, but does not warn about potential destructive effects of arbitrary commands, auth needs, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph with an important emphasis marker. It is front-loaded with key guidance and avoids unnecessary detail, but could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description should explain return format or error handling. It only states the tool 'captures its output' without specifics, and lacks details on potential risks or limitations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% coverage with descriptions for all three parameters. The description adds no additional parameter-level meaning beyond what the schema provides, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it executes shell commands in VS Code's integrated terminal and is the preferred method over run_terminal_cmd. Specific verb 'execute' and resource 'shell command' are well-defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to use this tool instead of the default run_terminal_cmd tool, providing clear when-to-use guidance. However, no when-not-to-use or alternative scenarios are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_active_tabsC

Retrieves information about currently open tabs in VS Code to provide context for the AI agent.

ParametersJSON Schema
NameRequiredDescriptionDefault
targetProjectPathYesPath to the project folder we are working in
includeContentNoWhether to include the file content of each tab (may be large)

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description fully bears the burden of disclosing behavior. It only states 'Retrieves' (implying read-only) but lacks details on side effects, permissions, or performance implications. The agent cannot assess safety or cost.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words. However, it could be more impactful by adding specific usage context. It is appropriately size for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description does not explain what information is returned (e.g., tab paths, titles, content). With no output schema, the agent is left guessing. The sibling 'get_context_tabs' may return similar data, increasing ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of parameters with descriptions. The description adds minimal new meaning beyond the schema, such as noting that context is provided for the AI agent. This meets the baseline but does not enhance agent understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Retrieves' and the resource 'currently open tabs in VS Code', making the purpose explicit. However, it does not differentiate from the sibling tool 'get_context_tabs', which may have overlapping functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_context_tabsB

Retrieves information about tabs that have been specifically marked for inclusion in AI context using the UI toggle in VS Code.

ParametersJSON Schema
NameRequiredDescriptionDefault
targetProjectPathYesPath to the project folder we are working in
includeContentNoWhether to include the file content of each tab (may be large)
selectionsNoOptional array of file paths with specific line ranges to include

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It explains the purpose but lacks details such as whether file content is returned, the potential size impact of includeContent, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the purpose with no unnecessary words, making it very concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and moderate complexity (3 params, one required), the description fails to explain the return format or behavior, such as whether it returns metadata or file content, leaving the agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all three parameters. The description adds some context about AI-focused tabs but no additional meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Retrieves' and the resource 'information about tabs marked for AI context', distinguishing it from sibling tool 'get_active_tabs' which likely retrieves all tabs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for context-marked tabs, but does not explicitly state when to use this tool over alternatives like get_active_tabs or provide any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_extension_portA

Get the port number that the VS Code MCP Extension is running on

ParametersJSON Schema
NameRequiredDescriptionDefault
targetProjectPathYesPath to the project folder we are working in

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description omits behavioral details such as whether the tool is read-only, what happens if the extension is not running, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no superfluous words, efficiently conveying the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple getter with one parameter, the description covers the basic purpose but lacks information on return values or error conditions, which could be expected for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear parameter description, but the tool description adds no additional meaning or context beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the port number of the VS Code MCP Extension, with a specific verb ('get') and resource ('port number'), and no sibling tool has a similar purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when needing the extension's port, but provides no explicit guidance on when to use this tool vs alternatives like check_extension_status or execute_shell_command.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_available_projectsA

Lists all available projects from the port registry file. Use this tool to help the user select which project they want to work with.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It mentions the data source ('port registry file') and implies a read-only operation. However, it does not explicitly state read-only or describe any side effects, though none are expected for a listing operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two concise sentences with no unnecessary words. It is front-loaded with the primary function and immediately specifies the intended usage scenario.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, no output schema, and a simple listing purpose, the description covers all necessary context: what it does and when to use it. No additional information is required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so schema coverage is 100%. The description does not need to add parameter details. According to guidelines, 0 parameters yields a baseline of 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool lists all available projects from the port registry file, with a specific verb 'Lists' and resource 'available projects'. It effectively distinguishes itself from sibling tools like 'open_project' which would operate on a selected project.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs to use this tool to help the user select a project, providing clear context for when to invoke it. It does not mention when not to use it or alternatives, but the simple nature of a listing tool makes this omission acceptable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

open_fileA

Used to open a file in the VS Code editor. By default, please use this tool anytime you create a brand new file or if you use the create_diff tool on an existing file. We want to see changed and newly created files in the editor.

ParametersJSON Schema
NameRequiredDescriptionDefault
filePathYesPath to the file to open
targetProjectPathYesPath to the project folder we are working in
viewColumnNoThe view column to open the file in (1, 2, 3, etc.)
preserveFocusNoWhether to preserve focus on the current editor
previewNoWhether to open the file in preview mode

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Only states 'opening a file', with no details on side effects, error handling, or what happens if file doesn't exist. Minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste. Front-loaded with core purpose, then usage guidance. Efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of opening a file and rich schema (5 params fully described), the description is adequate but lacks details on return behavior or edge cases. Could improve but not severely lacking.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline 3 applies. Description does not add meaning beyond schema, but schema already describes each parameter well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it opens a file in VS Code editor, and distinguishes from siblings like open_project. Provides specific usage guidance for new files and after create_diff.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use: for brand new files or after using create_diff on an existing file. Does not mention when not to use, but provides clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

open_projectA

Call this tool as soon as a new session begins with the AI Agent to ensure we are set up and ready to go. open_project opens a project folder in VS Code. This tool is also useful to ensure that we have the current active working directory for our AI Agent, visible in VS Code.

ParametersJSON Schema
NameRequiredDescriptionDefault
projectPathYesPath to the project folder to open in VS Code
newWindowNoWhether to open the project in a new window

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description lacks details on error handling, side effects (e.g., closing previous projects), or return behavior, which is important for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loading critical usage advice, with no superfluous wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool without output schema, the description adequately covers purpose and usage context, though it could mention what the return or state change is.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3; the description does not add significant meaning beyond the schema's parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('opens a project folder in VS Code') and the resource ('project folder'), and it is distinct from sibling tools like open_file and list_available_projects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance to call at session start and for ensuring active working directory, but does not mention when not to use or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 9 tool updatesv1.0.0
    • First observedcheck_extension_status
    • First observedcreate_diff
    • First observedexecute_shell_command
    • First observedget_active_tabs
    • First observedget_context_tabs
    • First observedget_extension_port
    • First observedlist_available_projects
    • First observedopen_file
    • First observedopen_project
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

Each tool has a clear and distinct purpose: checking extension status, creating diffs, executing commands, retrieving tab information, getting port, listing projects, opening files, and opening projects. No two tools overlap significantly.

Naming Consistency5/5

All tool names use consistent snake_case with verb_noun pattern (e.g., check_extension_status, open_file, list_available_projects). There is no mixing of conventions or vague verbs.

Tool Count5/5

9 tools is well-scoped for a VS Code MCP server. The count covers essential operations without being overwhelming or sparse.

Completeness4/5

The tool set covers core workflows like project setup, file modification, command execution, and context retrieval. However, there is no direct tool for reading file content, which agents must work around using execute_shell_command.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/juehang/vscode-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server