MCP Servers for VS Code: Five Useful Picks and How to Choose
MCP servers let VS Code connect an AI assistant to tools and information beyond the current chat, such as project files, GitHub issues, or a database. Five useful options are filesystem, GitHub, fetch, SQLite, and Playwright; choose one based on the task, the access it needs, and whether you can keep its permissions narrow.
What MCP servers do in VS Code
The Model Context Protocol (MCP) is a standard way for an AI application—a client—to discover and use capabilities provided by a server. An MCP server may expose tools the assistant can call, resources it can read, or prompt templates. It is not necessarily a separate machine: many servers run as local processes launched by the client, while others are hosted remotely.
VS Code’s MCP support is available through compatible AI features and extensions, and the exact setup experience depends on the client and its version. An MCP server does not automatically give every assistant access to everything on your computer. The client must be configured to connect, and the server’s tools, permissions, and approval behavior determine what it can do. Check the documentation for the specific VS Code feature or extension you use.
Five useful MCP server picks
- Filesystem: A practical choice for reading and working with files in specified directories. Restrict it to the project or folders needed for a task; broad access can expose unrelated or sensitive files. Some implementations also provide write operations, so inspect the available tools and permissions.
- GitHub: Useful when a coding task involves repositories, pull requests, issues, or related project information. Depending on the server and configuration, it may offer read or write operations. Use an appropriately scoped credential and confirm whether an action can change repository content before enabling it.
- Fetch: Helps retrieve and process content from web URLs, which can be useful for checking documentation or public pages alongside code. A fetch server is not the same as a fully interactive browser, and access to a URL does not guarantee the returned content is complete or trustworthy.
- SQLite: Connects an assistant to a SQLite database for questions about its schema or contents. It is a good fit for local development data and small application databases. Prefer read-only access when inspection is the goal, and avoid exposing production or personal data unnecessarily.
- Playwright: Supports browser automation and page interaction, making it useful for checking a local web app or reproducing a user flow. Browser actions can have consequences, particularly when signed in to a real account. Use a test environment and review what the server can access before running actions.
These are examples, not a required bundle. Names, capabilities, maintenance status, and installation methods vary among implementations. Find the project’s own documentation and verify that it supports the MCP transport and client configuration you intend to use.
How to choose the right server
Start with a concrete task rather than installing a collection of servers “just in case.” For example, if you need an assistant to summarize a repository’s open issues, GitHub may be enough. If you need it to inspect a local configuration file, a restricted filesystem server is more relevant. For a browser-based regression check, Playwright is a better match than a general web fetch tool.
- Match capability to the job. Identify whether you need local files, hosted repository data, web retrieval, database queries, or browser interaction.
- Check read and write behavior. Read-only access is usually sufficient for research and inspection. Enable changes only when the task requires them, and understand which tools can create, edit, delete, submit, or publish.
- Limit the scope. Set the smallest useful directory, repository, database, or account permission. Avoid using broad credentials where a narrower token or test account will work.
- Assess reliability and upkeep. Look for current documentation, supported setup instructions, clear configuration examples, and a credible maintenance history. A name appearing in a list does not establish that a particular implementation is safe or maintained.
- Try a low-risk task first. Confirm the server connects and returns expected information before using it on important files, accounts, or data.
Setup and connection basics
Most setups require installing or locating the server, then telling the MCP-capable VS Code client how to launch or reach it. A local server commonly needs a runtime or package manager; a remote server may require an address and authentication. Configuration formats and command names differ, so use the server’s current instructions rather than copying a configuration snippet intended for another client.
After configuration, the client generally needs to start or reconnect to the server, discover its tools, and make them available to the assistant. Depending on the client, you may be asked to approve tool calls. Treat that approval as a meaningful checkpoint: read the proposed action and its target, especially before allowing a write, shell-like operation, browser submission, or database change.
Safety, privacy, and common problems
MCP expands what an assistant can interact with; it does not make the assistant’s output inherently correct or safe. Tool results can be incomplete, and content retrieved from files or websites may contain misleading instructions. Review consequential actions yourself, and do not place secrets in prompts or expose sensitive data merely because a server can access it.
- Server does not appear: Check that the client supports MCP, the configuration is in the correct location and format, and the launch command or endpoint is valid. Restart or reconnect the client if its instructions require it.
- Launch fails: Confirm the required runtime is installed and available to the client process. Check the server’s error output for missing dependencies, invalid arguments, or environment variables.
- Permission denied: Verify the selected folder, account scope, database permissions, or credential. Do not respond by granting unrestricted access without understanding why the narrower permission failed.
- Tool is listed but does not work: Check whether the server is connected, whether the client has enabled the tool, and whether the requested operation is among its documented capabilities.
A common misconception is that installing an MCP server installs a model or automatically improves code quality. It does neither: it supplies a connection to tools or data, and the assistant still needs to choose and use those capabilities appropriately.
Frequently Asked Questions
Does VS Code include MCP servers by default?
No. MCP support depends on the VS Code feature or extension acting as the client, and servers generally need to be configured separately. Check the documentation for the client you use.
Are MCP servers the same as VS Code extensions?
No. An extension runs within the VS Code extension system; an MCP server exposes capabilities through the MCP protocol. A client may connect to a server, but the two are different components.
Can an MCP server edit my files?
Some filesystem implementations offer write tools and others may be configured more narrowly. Check the available tools and permissions, restrict accessible folders, and review proposed changes.
Do I need all five servers?
No. Install only what supports a real workflow. A server adds configuration and access to maintain, so a small, task-focused setup is often easier to understand and troubleshoot.
Is a local MCP server automatically safe?
No. Running locally does not guarantee safe code, limited access, or trustworthy results. Review the implementation, its permissions, its dependencies, and the actions the client can invoke.