Guide · Continue.dev

MCP server with Continue.dev — mcpServers config and tool integration

Continue.dev is an open-source AI coding assistant available as a VS Code and JetBrains extension. It supports MCP natively, letting you extend its capabilities with any MCP-compatible server. Continue's architecture distinguishes between "context providers" (sources that feed information into prompts) and "MCP tools" (functions the model can call). Understanding this distinction matters when you're deciding how to surface your server's capabilities. This guide covers the config format, transport options, the context provider vs. tool boundary, and how to verify your server is reliably reachable.

TL;DR

Edit ~/.continue/config.json and add an mcpServers array with your server's connection details. For local servers: use command + args. For remote servers: use url. Reload Continue by running "Continue: Reload config" from the VS Code command palette or restarting the extension. Verify in Continue's sidebar that your MCP tools appear in the tools list. For remote servers, add the URL to AliveMCP for protocol-level monitoring between coding sessions.

Config file location and format

Continue stores its configuration in ~/.continue/config.json (shared across all projects and editors). There is no project-scoped config file by default — all Continue settings, including MCP servers, live in the user-level config.

{
  "models": [ /* your LLM configuration */ ],
  "mcpServers": [
    {
      "name": "My MCP Server",
      "command": "node",
      "args": ["/path/to/dist/index.js"]
    }
  ]
}

The mcpServers field is an array (not an object keyed by name like Claude Desktop or Cursor). Each entry has a name field for display purposes plus the connection details.

Continue's config file supports a superset of the standard JSON format — you can add comments using // and trailing commas are allowed. This makes it easier to comment out servers you want to keep but temporarily disable without deleting the entry.

stdio transport: local server

For servers running on your local machine, stdio transport spawns the server as a subprocess:

{
  "mcpServers": [
    {
      "name": "Code Analysis Server",
      "command": "node",
      "args": ["/Users/you/projects/code-analysis-mcp/dist/index.js"],
      "env": {
        "DATABASE_URL": "postgresql://localhost:5432/analysis",
        "LOG_LEVEL": "warn",
        "NODE_ENV": "production"
      }
    }
  ]
}

Continue uses the same subprocess spawning behavior as Claude Desktop — it forks the process and communicates via stdin/stdout. The same rules apply:

Use absolute paths for command (avoid relying on PATH inheritance)
Never write to stdout before the MCP handshake is complete (no console.log in startup)
Direct all application logging to stderr or a file

For development with hot-reload, tsx --watch works as the command, but expect subprocess restarts to break in-progress tool calls when files change. Use compiled output for stability.

You can also run community-maintained servers directly with npx:

{
  "mcpServers": [
    {
      "name": "Filesystem",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/projects"]
    }
  ]
}

HTTP transport: remote server

For servers deployed remotely, use the url field pointing to the SSE endpoint:

{
  "mcpServers": [
    {
      "name": "Remote API Tools",
      "url": "https://my-mcp-server.fly.dev/sse"
    }
  ]
}

For servers that require authentication:

{
  "mcpServers": [
    {
      "name": "Authenticated API Tools",
      "url": "https://my-mcp-server.example.com/sse",
      "requestOptions": {
        "headers": {
          "Authorization": "Bearer your-api-key"
        }
      }
    }
  ]
}

Continue passes the requestOptions.headers with the SSE connection and any subsequent requests during the session. Avoid embedding production API keys directly in the config file. If you need per-developer keys, document a pattern for injecting them via environment variables read at Continue startup, or use a secrets manager integration.

See MCP server SSE transport for the server-side implementation of the SSE endpoint, including connection lifecycle management and reconnect handling.

Context providers vs. MCP tools: understanding the distinction

Continue has two mechanisms for bringing external data and capabilities into conversations:

Context providers are invoked with the @ symbol in Continue's chat input (e.g., @docs, @codebase, @url). They inject text content into the prompt context — documentation, code snippets, web pages. They are not callable functions; they return text that becomes part of the system context.

MCP tools from your mcpServers config are callable functions that the model can invoke during a conversation — similar to function calling. The model decides when to call a tool based on the conversation, calls it with structured arguments, and receives structured results.

The right choice depends on what your server does:

Use MCP tools for operations with side effects (write a file, call an API, run a query with parameters, send a notification). The model invokes these on demand.
Use context providers for read-only reference material that you want to inject at conversation start (documentation, schema definitions, project-specific context). These are more appropriate for Continue's custom context provider API than for MCP.

If you want both — dynamic tool calls AND rich context injection — implement them as separate mechanisms: tools in your MCP server, context injection via Continue's custom context provider API in config.ts. They're not mutually exclusive.

Reloading configuration

After editing config.json, reload Continue to pick up changes:

VS Code command palette (Cmd+Shift+P): run "Continue: Reload config"
JetBrains: restart the Continue plugin or use the reload button in the Continue tool window

Continue reconnects to all configured MCP servers after reload. New servers appear in the tools panel; removed servers disappear. If a server fails to connect, Continue logs the error in VS Code's Output panel — select "Continue" from the output channel dropdown to see MCP-specific errors.

Continue also watches config.json for file system changes and may hot-reload automatically in newer versions — check the Continue changelog for the current behavior in your installed version.

Verifying tool availability

After reloading, verify your MCP tools are available by checking Continue's tool list in the sidebar. Tools from all connected servers appear in a merged list. If your tools are missing:

Check the VS Code Output panel → "Continue" channel for connection error messages
Run the MCP inspector manually to confirm the server initializes and advertises tools correctly: npx @modelcontextprotocol/inspector node /path/to/dist/index.js
Confirm the tools/list response contains your tool definitions with valid names and input schemas

Tool names must be unique across all connected servers. If two servers expose a tool with the same name, behavior is undefined — rename one of the tools or prefix them with a namespace (myserver_search instead of search).

To test a tool call directly, use a Continue conversation: ask the model explicitly to "use the [tool_name] tool to [do something]". Continue will show the tool call in the conversation UI, including the arguments passed and the result returned. This is useful for verifying the full round-trip without needing to build a dedicated test client.

Using config.ts for dynamic configuration

Continue supports a TypeScript config file (~/.continue/config.ts) for programmatic configuration. This is useful when you need to dynamically construct the MCP server list based on environment variables or local project state:

// ~/.continue/config.ts
import type { ContinueConfig } from "@continuedev/config-types";

export function modifyConfig(config: ContinueConfig): ContinueConfig {
  return {
    ...config,
    mcpServers: [
      ...(config.mcpServers || []),
      {
        name: "My Dynamic Server",
        command: process.env.MCP_SERVER_COMMAND || "node",
        args: [process.env.MCP_SERVER_PATH || "/default/path/dist/index.js"],
        env: {
          API_KEY: process.env.MY_API_KEY || "",
        }
      }
    ]
  };
}

The config.ts approach lets you read secrets from environment variables rather than hardcoding them in the JSON config, keeping credentials out of files that might accidentally be committed or backed up to cloud storage.

Monitoring remote MCP servers used from Continue

Continue's MCP connection status is visible only while VS Code is running and you're actively using Continue. Remote servers can go down, have SSL certificates expire, or degrade in ways that only surface when the model tries to call a tool during a session.

For remote MCP servers connected to Continue, add the server URL to AliveMCP. AliveMCP runs the full initialize → tools/list probe sequence from an external network on a regular schedule, alerting you when the MCP protocol layer fails — before your next coding session surfaces a confusing tool call error. It catches certificate expiry, DNS failures, and deployment issues that don't affect HTTP responses but break the MCP protocol layer.

See MCP server health checks for how to implement a thorough /healthz endpoint that mirrors what AliveMCP verifies externally.