Last updated: July 2026 · Covers Cline, Cursor, Continue.dev, Claude Code, and Windsurf
MCP (Model Context Protocol) is the standard that lets AI coding agents connect to external tools and data — databases, deployment systems, documentation, issue trackers, web search — instead of only seeing the files in your editor. Most developers have heard the term but have never actually configured a server, largely because official documentation is scattered across each tool's own docs with no single practical walkthrough.
This guide covers what MCP actually does, how to set up servers in the major AI coding tools, which servers are worth installing first, and how to troubleshoot the setup when it does not work on the first try.
Without MCP, an AI coding agent's knowledge is limited to whatever files are open or explicitly added to its context. It can read your code, but it cannot query your production database, check whether a CI build passed, look up a library's current API in official docs, or create a ticket in your issue tracker.
MCP servers close that gap. Each server exposes a specific set of capabilities — "query this PostgreSQL database," "search GitHub issues," "read pages from this documentation site" — through a standardized interface that any MCP-compatible tool can use. You install a server once, and any of your MCP-compatible AI tools can call it.
The practical effect: instead of manually copying a database schema into a chat prompt, or pasting error output from a CI dashboard, the agent can retrieve that information itself, mid-task, whenever it decides the information is relevant.
For the underlying protocol definitions (MCP Server, ACP, and related terms), see the AI Coding Tools Glossary.
A supported AI coding tool. MCP support and ease of setup varies significantly by tool — covered tool-by-tool below. Cline has the most mature implementation; Cursor and Windsurf support MCP but with more manual configuration.
Node.js installed. The overwhelming majority of MCP servers are distributed as npm packages and run via npx. If you do not have Node.js installed, install it before proceeding — most servers will fail silently or with a confusing error if npx is unavailable.
Credentials for whatever you are connecting to. A database connection string, a GitHub personal access token, an API key for a search provider — whatever the specific server needs. Have these ready before configuring; most setup friction comes from credential issues, not the MCP configuration itself.
Cline has the most developed MCP ecosystem of any tool covered on this site, including a dedicated marketplace for browsing and installing servers with minimal manual configuration.
Open the Cline panel in VS Code → click the MCP icon in the sidebar → Marketplace tab. Browse by category (databases, deployment, search, documentation) or search by name. Click Install on a server, and Cline handles the installation and configuration automatically, prompting you for any required credentials.
For servers not in the marketplace, or for full control over configuration, edit Cline's MCP settings directly:
VS Code Settings → Cline → MCP Servers → Configure MCP Servers (opens cline_mcp_settings.json)
{
"mcpServers": {
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres"],
"env": {
"POSTGRES_CONNECTION_STRING": "postgresql://user:pass@localhost:5432/mydb"
}
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_your_token_here"
}
}
}
}
Save the file. Cline detects the change and loads the new servers — no restart required in most cases.
A distinctive Cline capability: you can ask it to create a new MCP server for a capability that does not exist yet.
Add an MCP tool that lets you query our Stripe account for recent
failed payments.
Cline will scaffold, configure, and install a working MCP server for that specific task. This works well for simple, well-defined integrations against documented APIs; more complex integrations still benefit from manual review of the generated server code.
For full Cline configuration beyond MCP, see the Cline Rules guide.
Cursor supports MCP but with a more basic implementation than Cline — no marketplace, manual JSON configuration only, and a documented limit of 40 tools per configuration.
Cursor Settings → Features → MCP → Add New MCP Server, or edit the config file directly:
.cursor/mcp.json (project-level) or ~/.cursor/mcp.json (global)
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/directory"]
},
"brave-search": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-brave-search"],
"env": {
"BRAVE_API_KEY": "your_api_key_here"
}
}
}
}
Restart Cursor after editing the config file — unlike Cline, changes are not always picked up live.
If you connect several MCP servers, each exposing multiple tools, you can hit Cursor's 40-tool ceiling faster than expected — a database server alone might expose 8–10 distinct tools (query, list tables, describe schema, etc.). If you hit the limit, disable servers you are not actively using for the current task rather than keeping everything connected simultaneously.
For general Cursor configuration, see the Cursor Rules guide. For a direct comparison of Cursor's MCP support against Cline's marketplace approach, see Cursor vs Cline.
Continue.dev configures MCP servers directly in config.yaml, consistent with how it handles models, rules, and context providers.
mcpServers:
- name: postgres
command: npx
args: ["-y", "@modelcontextprotocol/server-postgres"]
env:
POSTGRES_CONNECTION_STRING: ${{ secrets.DATABASE_URL }}
- name: github
command: npx
args: ["-y", "@modelcontextprotocol/server-github"]
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Continue.dev's secrets. namespace automatically resolves values from your .env file, meaning credentials do not need to be hardcoded directly into config.yaml — a meaningful advantage for teams committing this file to a shared repository. See the Continue.dev Rules guide for the full secrets resolution setup.
Claude Code manages MCP servers through the CLI directly, rather than editing a config file by hand for the initial setup.
# Add a server
claude mcp add postgres -- npx -y @modelcontextprotocol/server-postgres
# Add a server with environment variables
claude mcp add github -e GITHUB_TOKEN=ghp_your_token -- npx -y @modelcontextprotocol/server-github
# List configured servers
claude mcp list
# Remove a server
claude mcp remove postgres
This writes the configuration to Claude Code's settings automatically. For project-specific servers versus global ones, use the --scope flag (local, project, or user) to control where the configuration is stored — project-scoped servers can be committed to the repository so the whole team gets the same MCP setup automatically.
For general Claude Code configuration, see the Claude Code Rules guide.
Windsurf supports MCP through its settings panel, with a configuration approach similar to Cursor's.
Windsurf Settings → Cascade → MCP Servers → Add Server, or edit directly:
~/.codeium/windsurf/mcp_config.json
{
"mcpServers": {
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres"],
"env": {
"POSTGRES_CONNECTION_STRING": "postgresql://user:pass@localhost:5432/mydb"
}
}
}
}
Windsurf's MCP support is functional but less commonly used in practice than Cline's, since Cascade's autonomous agent style leans more on file-based context than on external tool calls for most everyday tasks.
Most developers get the most practical value from a small set of servers rather than connecting everything available. In rough order of general usefulness:
Filesystem — read/write access scoped to a specific directory, useful for agents working outside your primary project folder (shared assets, documentation repos).
GitHub — query issues, pull requests, and repository metadata directly. Particularly useful for "summarize open issues related to X" or "check if this PR has unresolved review comments" style tasks.
PostgreSQL / your database — lets the agent inspect schema, run read queries, and understand your actual data shape when writing code that touches the database, rather than guessing from ORM model definitions alone.
Brave Search / web search — gives the agent access to current information beyond its training data, useful for checking a library's latest API or confirming a fact that may have changed since training.
Slack — post updates or query recent messages, useful for agent workflows that need to notify a channel on completion or pull context from a discussion thread.
Puppeteer / browser automation — lets the agent open a browser, navigate, click, and screenshot — useful for visual debugging or end-to-end testing tasks. Cline includes browser automation built in without requiring a separate MCP server for this specific capability.
Install incrementally rather than connecting everything at once — each active server adds tool definitions to every request, consuming context budget whether or not it is used for a given task.
The official MCP servers repository (github.com/modelcontextprotocol/servers) maintains a curated list of servers built and maintained by Anthropic and the community, covering common integrations (databases, cloud providers, SaaS tools). Cline's in-app marketplace surfaces a subset of these plus community-built servers directly inside the editor.
For integrations without an existing server, most MCP servers are simple enough to build from a template — a server is fundamentally a small program that exposes a defined set of functions over the MCP protocol. This is a reasonable weekend project for a specific internal tool your team uses regularly, and Cline's ability to scaffold one from a natural-language description (covered above) is often faster than writing one from scratch.
MCP servers can be a meaningful attack surface if configured carelessly, since they grant an AI agent — which follows instructions embedded in file content, chat, and sometimes tool output — direct access to systems like databases and cloud infrastructure.
Scope credentials narrowly. A database connection string used for an MCP server should use a read-only role wherever the task allows it, rather than a full-access admin credential. If the agent only needs to read schema and run SELECT queries, do not give it a connection with write or DDL permissions.
Be cautious with filesystem server scope. The filesystem MCP server takes a directory argument that defines its access boundary. Scope it to the specific folder needed, not your entire home directory or drive root.
Review auto-generated servers before trusting them broadly. When an agent scaffolds a new MCP server for you (as covered in the Cline section above), review the generated code before connecting it to anything sensitive — treat it the same as any other AI-generated code that touches credentials or external systems.
Understand prompt injection risk. Content retrieved through an MCP server (a database record, a web page, a GitHub issue body) becomes part of the agent's context, and if that content contains text designed to manipulate the agent's behavior, a poorly designed agent could act on it. This is an active area of development across the MCP ecosystem; being aware of the risk is more important than any single mitigation, particularly when connecting servers that pull in content from sources outside your direct control.
For a broader security and compliance framework beyond MCP specifically, see AI Coding Tools for Teams: Enterprise Guide.
Confirm npx runs successfully from your terminal independent of the AI tool — npx -y @modelcontextprotocol/server-github --help should execute without error. If it fails at the terminal, the issue is Node.js/npx setup, not your AI tool's configuration.
Usually a credentials issue. Double-check environment variable names match exactly what the specific server expects (check the server's own README — naming is not standardized across servers), and confirm the credential itself is valid and has the necessary permissions for what you are asking the agent to do.
Cline typically detects changes live; Cursor, Windsurf, and Claude Code more often require a restart of the tool (or, for Claude Code, starting a new session) after editing MCP configuration directly rather than through the CLI/marketplace flow.
Each connected server adds tool definitions to every request's context. If you have 5+ servers connected with overlapping capability, disable the ones not relevant to your current task rather than leaving everything active by default.
MCP (Model Context Protocol) is a standard that lets AI coding agents connect to external systems — databases, APIs, documentation, issue trackers — through a consistent interface, rather than each tool building its own one-off integration for each service. One MCP server, once built, works with any MCP-compatible AI tool.
Cline has the most developed MCP implementation, including a marketplace for one-click installation and the ability to auto-generate new servers from a natural-language description. Cursor and Windsurf support MCP but require more manual JSON configuration. Continue.dev and Claude Code both support MCP with configuration integrated into their respective config systems.
No, for the common case of installing an existing server (database, GitHub, search) — this is JSON configuration and credential entry, not coding. Building a new server from scratch for a custom integration does involve writing code, though Cline's auto-generation feature reduces this to a natural-language request for straightforward cases.
Only with a read-only, narrowly scoped credential, and only if you trust the specific server's implementation (official servers from the modelcontextprotocol/servers repository are the safer default over unfamiliar community servers). For genuinely sensitive production data, consider connecting to a read replica or a database with representative but non-sensitive data instead.
Yes — this is the core value of the protocol being standardized. The same PostgreSQL MCP server, for instance, can be configured in Cline, Cursor, and Continue.dev independently, each pointing to the same underlying server package, without needing tool-specific integrations.
Confirm the server actually loaded successfully (check for errors in the tool's output/logs) and that the task you gave the agent plausibly requires the tool's capability — agents generally only invoke a tool when the task description makes its relevance clear. Being explicit ("check the database for...", "look up the GitHub issue about...") improves the odds the agent recognizes when to use a connected tool, particularly early in a session before it has established a pattern of using it.