Cline MCP Servers: The Marketplace, the Local Servers, and the Configuration That Actually Works

Cline (the VS Code AI extension) loads MCP servers from three sources: the marketplace (one-click install, the trust trade-off), community repos (curated servers, the maintenance question), and the team’s own deploy (the production answer). The configuration that actually works is the cline_mcp_settings.json file with the server’s URL, the tool scope, the environment variables, and the version pin. The right source depends on whether the server is a quick experiment, a long-term dependency, or a production tool the team will own.

This post walks through the three sources, the configuration file shape, the tool scoping pattern, the version pin, and the diagnostic for “CLI cannot find MCP servers” (the most common first-day error).

Table of contents

• The three sources of Cline MCP servers
• The marketplace: one-click, but at a cost
• The community repos: curated, but unmaintained
• The team’s own deploy: the production answer
• The configuration file: cline_mcp_settings.json
• The tool scoping pattern
• The version pin
• The diagnostic for “CLI cannot find MCP servers”
• How this fits the rest of the stack
• FAQ

The three sources of Cline MCP servers

The three sources, in order of trust and effort:

1. The marketplace. One-click install from Cline’s marketplace. The marketplace has curated servers (Postgres, GitHub, Notion, etc.) and community-contributed servers. The install writes the configuration file and starts the server.
2. Community repos. GitHub repos of curated MCP servers (often organized by topic: awesome-mcp-servers, modelcontextprotocol/servers, etc.). The team clones the repo, installs the dependencies, and adds the server to the configuration.
3. The team’s own deploy. The team writes the MCP server, deploys it to a managed platform, and adds the URL to the configuration. The pattern is the right answer for production.

The right source depends on whether the server is a quick experiment (use the marketplace), a long-term dependency on a third party (use the community repo, with the maintenance question answered), or a production tool the team will own (deploy it).

The marketplace: one-click, but at a cost

The marketplace is the fastest path. The team opens Cline, clicks the MCP tab, browses the marketplace, clicks “Install” on the server they want, and the server is configured. The whole flow takes 30 seconds.

The cost is the trust. The marketplace server is a third-party process that runs locally (or remotely, depending on the server) with the team’s credentials. The team has to trust:

• The server is not malicious. The marketplace has a curation process, but the curation is not perfect.
• The server is maintained. The marketplace server may be abandoned. The team that installs a maintained server today may have a broken server in six months.
• The server is the version the team wants. The marketplace server may have been updated to a version that does not match the team’s Cline version, or to a version with breaking changes.

The right answer for the marketplace is the quick experiment. The team that wants to try a server uses the marketplace. The team that wants to depend on a server long-term does not.

The community repos: curated, but unmaintained

The community repos are the right answer for the team that wants a server the marketplace does not have, or a server the marketplace has but the team does not trust. The team clones the repo, installs the dependencies, and adds the server to the configuration.

The gotcha: the community repos are not maintained. The team that depends on a community repo has to fork it, pin the version, and maintain the fork. The maintenance is the cost the team pays for not using the marketplace or the team’s own deploy.

The second gotcha: the community repos do not always have a Dockerfile. The team that wants to deploy a community server to production has to write the Dockerfile. The pattern is to use the repo’s existing setup, wrap it in a Dockerfile, and deploy.

The team’s own deploy: the production answer

The team’s own deploy is the right answer for any MCP server the team will use long-term. The pattern is: the team writes the server (or wraps an existing server in a Dockerfile), deploys it to a managed platform, and adds the platform’s URL to the Cline configuration.

The benefits:

• The team owns the server. The team can fix bugs, add features, and update the version on their schedule. The marketplace and community repos do not block the team.
• The team controls the credentials. The server’s credentials are the team’s credentials, not the marketplace’s or the community’s.
• The team’s logs are the team’s logs. The deploy platform’s logs are the source of truth for the server’s behavior. The team can debug from the team’s own dashboard.

The gotcha: the team’s own deploy is the highest-effort option. The team has to write the server, write the Dockerfile, set up the deploy pipeline, and maintain the deploy. The right answer is to use the marketplace or the community repo for the quick experiment, and to deploy the team’s own server once the team has decided to keep it.

The configuration file: cline_mcp_settings.json

The configuration file is the source of truth for which MCP servers Cline loads. The file is at ~/.cline/cline_mcp_settings.json on the user’s machine, and the file is per-user (not per-project).

The shape:

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "type": "http",
      "headers": {
        "Authorization": "Bearer ${env:GITHUB_TOKEN}"
      },
      "disabled": false,
      "autoApprove": ["list_repos", "search_code"]
    },
    "postgres": {
      "command": "uvx",
      "args": ["mcp-server-postgres", "--connection-string", "${env:DATABASE_URL}"],
      "disabled": false
    }
  }
}

The file is a map of server name to server config. Each server has a url (for HTTP) or a command/args (for stdio), a disabled flag, and an optional autoApprove list of tools the agent can call without confirmation.

The gotcha: the ${env:VAR_NAME} syntax is the right way to reference environment variables in the configuration. The team that hardcodes the token in the file has leaked the token to disk.

The second gotcha: the disabled flag is per-server, not per-tool. The team that wants to disable one tool on a server uses the autoApprove list as a deny list, or uses a server that supports per-tool disable.

The tool scoping pattern

The tool scoping pattern is the most important security decision in the Cline configuration. The pattern is: list the tools the agent can call without confirmation in autoApprove, and the rest require confirmation.

The right pattern for a GitHub server:

"autoApprove": ["list_repos", "search_code", "get_file"]

The right pattern for a Postgres server (read-only):

"autoApprove": ["list_tables", "describe_table", "run_query"]

The gotcha: the autoApprove list is read-only by default. The team that adds drop_table or delete_user to the list has given the agent the ability to make destructive changes without confirmation. The right answer is to keep autoApprove to the read-only tools, and to require confirmation for everything else.

The second gotcha: the autoApprove list is per-server, not per-tool. The team that wants to disable one tool on a server (without disabling the whole server) has to fork the server and remove the tool.

The version pin

The version pin is the part that prevents the marketplace or the community repo from breaking the team’s setup with an update. The pattern is: pin the version in the configuration, and update the version deliberately.

For a stdio server (using uvx or npx), the pin is in the package version:

"args": ["[email protected]", "--connection-string", "${env:DATABASE_URL}"]

For an HTTP server, the pin is in the URL (the platform’s URL is stable, the team does not need to pin).

The gotcha: the pin is a maintenance burden. The team that pins a version has to update the pin to get security patches. The right answer is to pin the major version (@1) and let the minor and patch versions float, or to pin the exact version and update on a schedule.

The diagnostic for “CLI cannot find MCP servers”

The most common first-day error is “CLI cannot find MCP servers” (Cline cannot load any of the servers in the configuration). The diagnostic:

1. Check the configuration file path. The file is at ~/.cline/cline_mcp_settings.json. The Cline docs confirm the path. The team that has the file in the wrong directory has a silent failure.
2. Check the JSON syntax. The file is JSON, not JSON5. Trailing commas, comments, and single quotes are not allowed. The team that pastes from a doc that has comments has a parse error.
3. Check the environment variables. The ${env:VAR_NAME} references the environment. The team that has not set the variable has a silent failure (the server starts, the call fails).
4. Check the server URL or command. The url for HTTP or the command/args for stdio. The team that has a typo has a silent failure.
5. Check the Cline logs. The Cline “Output” panel shows the server load errors. The team that does not check the logs is debugging blind.

The diagnostic takes 5 minutes. The fix is usually one of: file path, JSON syntax, env var, URL, or command.

How this fits the rest of the stack

The MCP server pattern is also a hosting pattern. The team’s deployed server is a service on a platform, the platform runs the service, and the team owns the server. The platform decision is also a cost decision — the runtime, the memory, the storage, the bandwidth, and the egress each show up as a line item, and the team’s mental model for the project cost is the sum of those numbers. The RunxBuild hosting calculator is the right place to do that exercise — pick the runtime size, the memory tier, the storage, the expected request volume, and the bandwidth, and the calculator shows what the MCP server actually costs at the team’s actual usage.

Useful related references:

• MCP server config
• MCP server build
• services layer

FAQ

What is a Cline MCP server?

A Cline MCP server is an MCP server that the Cline VS Code extension loads from its configuration file. The server can come from the marketplace, a community repo, or the team’s own deploy. The server’s tools, resources, and prompts are available to Cline’s agent.

How do I add an MCP server to Cline?

Edit ~/.cline/cline_mcp_settings.json and add a mcpServers entry. The entry has a url (for HTTP) or a command/args (for stdio), a disabled flag, and an optional autoApprove list.

Should I use the marketplace or my own deploy?

The marketplace for quick experiments. The team’s own deploy for production. The community repos for the cases the marketplace does not have.

How do I scope which tools the agent can call without confirmation?

The autoApprove list in the server’s configuration. The list contains the tool names the agent can call without confirmation. The rest of the tools require confirmation.

How do I pin the version of a stdio MCP server?

Pin the version in the args: ["[email protected]", ...]. The pin prevents the server from updating without the team’s knowledge.

Why is Cline showing “CLI cannot find MCP servers”?

Five common causes: the configuration file is in the wrong directory, the JSON syntax is invalid, the environment variables are not set, the URL or command is wrong, or the Cline logs are showing an error. The diagnostic in the article walks through each.

Can I use a remote MCP server with Cline?

Yes. The url in the server’s configuration points to the remote server. Cline connects over HTTP. The remote server is the production answer for any server the team will use long-term.

How do I debug a Cline MCP server?

Open the Cline “Output” panel and read the logs. The logs show the server load errors, the env var resolution, the JSON-RPC calls, and the tool results. The diagnostic in the article walks through the most common errors.