Integrations10 min read

MCP Integration Guide: Continue.dev — Add MCP Tools to Your AI Coding Assistant

Complete guide to connecting MCP servers with Continue.dev, the open-source AI coding assistant. Configure MCP tools in Continue, use context providers, and build a custom AI coding workflow with your own tool ecosystem.

By MyMCPTools Team·

Continue.dev is an open-source AI coding assistant that runs inside VS Code and JetBrains IDEs. Unlike Copilot or Cursor, Continue gives you complete control over which models and tools your coding AI uses — including MCP servers. Connecting MCP servers to Continue lets your coding assistant query databases, read documentation, check GitHub issues, and run shell commands directly from your editor.

What Continue.dev's MCP Support Enables

Continue.dev added native MCP support as a first-class feature. MCP servers appear as context providers and tools in Continue's interface, which means you can:

  • Use @mcp-tool mentions to pull context from any MCP server into your chat
  • Let the AI call MCP tools autonomously during agentic coding sessions
  • Mix MCP-sourced context with file context (@file), codebase search (@codebase), and docs (@docs)

Step 1: Install Continue.dev

Install the Continue extension from the VS Code Marketplace or JetBrains Plugin Marketplace. The extension creates a ~/.continue/config.json file where all configuration lives.

Step 2: Configure MCP Servers in Continue

Open ~/.continue/config.json and add an mcpServers section:

{
  "models": [...],
  "mcpServers": [
    {
      "name": "GitHub",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_your_token_here"
      }
    },
    {
      "name": "Postgres",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost/mydb"]
    },
    {
      "name": "Filesystem",
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/you/projects"
      ]
    },
    {
      "name": "Fetch",
      "command": "uvx",
      "args": ["mcp-server-fetch"]
    }
  ]
}

After saving, Continue automatically starts each MCP server as a subprocess. Tools from all configured servers are available in the chat interface.

Step 3: Use MCP Tools in Chat

Continue exposes MCP tools in two ways:

As context providers (@mentions): Type @ in the chat to see available context providers. MCP servers that expose resource-type tools appear here. For example, with the GitHub MCP server, you might see @GitHub Issues or @GitHub PR.

As tools (autonomous use): In agent mode, Continue's AI can call MCP tools automatically. When you ask "Fix the bug mentioned in GitHub issue #234," Continue can fetch the issue via the GitHub MCP server, read the relevant code, apply a fix, and run tests — all without leaving your editor.

Step 4: Configure Per-Project MCP Servers

For project-specific MCP servers (like a database or API specific to one project), use a local Continue config that extends your global one. Create .continue/config.json in your project root:

{
  "mcpServers": [
    {
      "name": "Project DB",
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://localhost/project_db"
      ]
    },
    {
      "name": "Project Docs",
      "command": "node",
      "args": ["./scripts/mcp-docs-server.js"]
    }
  ]
}

Continue merges the project config with your global config, so project-specific servers are available only when you're working in that directory.

Step 5: Build a Coding Workflow with MCP Context

Here's a practical workflow combining multiple MCP servers for a full-stack feature:

  1. Fetch requirements from GitHub — ask Continue to read the issue and linked PR comments via the GitHub MCP server
  2. Query the schema — "Show me the current users table structure" pulls from the Postgres MCP server
  3. Generate the migration — Continue writes the SQL migration based on the issue requirements and current schema
  4. Apply and verify — use a shell MCP server to run psql and verify the migration applied correctly
  5. Write the endpoint — Continue generates the API handler with full context of the schema change

Using HTTP-Based MCP Servers

For MCP servers running remotely (team-shared servers, cloud-deployed instances), Continue supports SSE transport:

{
  "mcpServers": [
    {
      "name": "Team Knowledge Base",
      "url": "https://mcp.yourteam.com/sse",
      "headers": {
        "Authorization": "Bearer your-token"
      }
    }
  ]
}

This is particularly useful for sharing a single MCP server instance (like an internal documentation server or a company-wide database proxy) across your entire engineering team.

Recommended MCP Servers for Coding Workflows

  • GitHub MCP server — issue context, PR reviews, code search
  • Filesystem MCP server — read/write project files outside the current editor view
  • Postgres/SQLite MCP server — live schema context for SQL generation
  • Fetch MCP server — pull documentation, API specs, or Stack Overflow answers
  • Git MCP server — commit history, diff context, branch information
  • Shell/Exec MCP server — run tests, linters, and build commands inline

Troubleshooting

Server not starting: Check Continue's output panel (View → Output → Continue) for MCP server startup errors. Common cause: missing environment variables or incorrect path to the MCP server binary.

Tools not appearing: MCP servers must be running and healthy for their tools to appear. Restart Continue after adding new servers. Check that npx or uvx can reach the package registry from your environment.

Rate limits: MCP servers calling external APIs can hit rate limits during intensive coding sessions. Add caching at the MCP server level or configure rate limits in the server's environment variables.

Explore the MCP server directory for tools to add to your Continue.dev setup, and check our Cursor MCP integration guide and VS Code MCP guide for comparison.

Recommended Tools

Better Stack

Free Plan

Get alerted when your APIs, browser tests, payment pipelines, or MCP server dependencies go down. Used by 100K+ developers.

Start monitoring free →

1Password

14-day Free Trial

Store and inject API keys, payment credentials, tokens, and file access secrets into your MCP server configs. Trusted by 150K+ developers.

Try 1Password free →

🔧 MCP Servers Mentioned in This Article

💻

GitHub MCP Server

authenticated access to the whole GitHub platform — repositories, files, branches, issues, pull requests, Actions runs, security alerts, discussions and notifications — from Claude, Cursor, VS Code, Copilot CLI and any other MCP host. There is no npm package for this server, and that trips up most people who try to install it: `@github/mcp-server` is not published to the npm registry, so any `npx` line you find for it will fail. GitHub ships it three other ways. The easiest is the hosted remote server at https://api.githubcopilot.com/mcp/, which needs no install at all — point an HTTP-transport MCP client at that URL and log in with OAuth (VS Code 1.101+, Claude Desktop, Claude Code, Cursor and Windsurf all support this). The second is the official Docker image ghcr.io/github/github-mcp-server, which is what the copy-paste command on this page runs; on github.com it now performs a browser-based OAuth login on first use and keeps the token in memory only, which is why the published Docker configs map a fixed loopback callback port (-p 127.0.0.1:8085:8085 with GITHUB_OAUTH_CALLBACK_PORT=8085) so the container can receive the callback. Prefer a token? Set GITHUB_PERSONAL_ACCESS_TOKEN instead — it takes precedence over OAuth, and the minimum useful scopes are repo, read:org and read:packages. The third is the native Go binary from the repository's releases, which needs no fixed port for the OAuth flow. GitHub Enterprise Server has no hosted option: use the local server with --gh-host or GITHUB_HOST set to your instance (include the https:// scheme — it defaults to http://, which GHES rejects). Toolsets can be narrowed with GITHUB_TOOLSETS, and an insiders channel is available at /mcp/insiders or via the X-MCP-Insiders header.

Auth required📘
🌐

Fetch

Web content fetching and conversion for efficient LLM usage. Extract readable content from any URL.

Local
📁

Filesystem MCP Server

sandboxed read, write, edit, move and search access to an explicit whitelist of local directories, and it is the reference implementation most other filesystem MCP servers are modelled on. Shipped by Anthropic in the official modelcontextprotocol/servers monorepo (89,000+ stars, actively maintained), it is a Node.js server published to npm as @modelcontextprotocol/server-filesystem. The part worth understanding before you install is the access-control model, because there are now two ways to grant directories and they do not compose. Method one is command-line arguments: `npx -y @modelcontextprotocol/server-filesystem /path/one /path/two`. Method two, and the one the maintainers recommend, is MCP Roots — a client that supports the roots protocol sends its roots at initialization, and those roots COMPLETELY REPLACE any directories passed on the command line, then get replaced again on every `notifications/roots/list_changed`. That means allowed directories can change at runtime without restarting the server, but it also means a roots-capable client silently overrides your CLI arguments. If the server starts with no arguments and the client either does not support roots or sends an empty list, initialization throws an error. The tool surface is broad: `read_text_file` (with mutually exclusive `head`/`tail` line windows), `read_media_file` returning base64 image/audio content blocks, `read_multiple_files` which keeps going when individual reads fail, `write_file`, `edit_file`, `create_directory`, `list_directory`, `list_directory_with_sizes`, `move_file`, `search_files`, `directory_tree`, `get_file_info` and `list_allowed_directories`. `edit_file` is the one to learn — it does line-based and multi-line pattern matching with indentation detection and preservation, returns a git-style diff with context, and supports `dryRun: true` so you can preview a change before applying it; the maintainers recommend always running a dry run first. Every operation is refused outside the allowed set, and `list_allowed_directories` is the fastest way to confirm what the server actually believes it can touch.

Local
🔧

Docker MCP Server

The Docker MCP server (ckreiling/mcp-server-docker) gives an AI assistant direct control of a Docker daemon over the Model Context Protocol: containers, images, networks and volumes, as tools rather than shell commands. It is the community server most people mean by "Docker MCP" — distinct from Docker’s own Docker MCP Gateway, which does not manage your containers at all but runs *other* MCP servers inside containers. If you want to ask Claude why the postgres container keeps restarting, you want this one; if you want a single secure endpoint in front of twenty catalog servers, you want the gateway. The tool surface is explicit and small enough to reason about: list_containers, create_container, run_container, recreate_container, start_container, fetch_container_logs, stop_container and remove_container for containers; list_images, pull_image, push_image, build_image and remove_image for images; list_networks / create_network / remove_network and list_volumes / create_volume / remove_volume for the rest. Two resource templates, docker://containers/{id}/logs and docker://containers/{id}/stats, let a client read logs and live stats by container ID or name without a tool call. It also ships a docker_compose prompt that puts the model into a plan-then-apply loop — you describe the containers you want under a project name, the model proposes a concise plan, and nothing runs until you approve it; reopening the prompt with the same project name re-reads the state of everything created under it, which is how you clean up after a lost chat. It runs on the Python Docker SDK’s from_env, so DOCKER_HOST applies: set ssh://user@host and the same server administers a remote engine. Two limits are deliberate and stated by the project — privileged options like --privileged and --cap-add/--cap-drop are not supported, and container configuration passes through the model, so no secrets belong in it.

Local📘

📚 More from the Blog