> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/cline/cline/llms.txt
> Use this file to discover all available pages before exploring further.

# MCP Overview

> Learn what the Model Context Protocol (MCP) is, how it works, and how Cline uses it to connect your AI assistant to external tools, APIs, and data sources.

Model Context Protocol (MCP) is an open standard that defines how AI applications communicate with external tools and data sources. Think of it as a USB-C port for AI: a single, universal interface that lets an AI model plug into anything — databases, APIs, file systems, browser automation, and more.

MCP servers are the programs that implement this protocol. Each server exposes a set of **tools** (functions the AI can call) and optionally **resources** (read-only data the AI can reference). Cline acts as the MCP client, discovering available tools and invoking them on your behalf.

<Columns cols={2}>
  <Card title="MCP Marketplace" icon="store" href="/mcp/mcp-marketplace">
    Browse and install pre-built MCP servers directly inside Cline.
  </Card>

  <Card title="Adding servers manually" icon="sliders" href="/mcp/adding-and-configuring-servers">
    Edit the MCP config JSON to add, configure, and manage servers.
  </Card>

  <Card title="Build your own server" icon="code" href="/mcp/mcp-server-development-protocol">
    Use the MCP SDK and Cline's dev protocol to build a custom server.
  </Card>

  <Card title="Official MCP servers" icon="github" href="https://github.com/modelcontextprotocol/servers">
    Browse the official collection of reference MCP server implementations.
  </Card>
</Columns>

## How MCP works

At its core, MCP is a client–server architecture layered on top of a transport (either local stdio or remote HTTP). When Cline starts, it reads your MCP configuration, launches each enabled server as a subprocess (or connects to a remote endpoint), and queries the server for its list of tools and resources. Those capabilities are then available to Cline during every conversation.

```plaintext theme={null}
┌──────────────────────────────────────────────┐
│                   Cline (MCP client)         │
│  - Reads cline_mcp_settings.json             │
│  - Launches / connects to servers            │
│  - Calls tools, reads resources              │
└───────────────┬──────────────────────────────┘
                │  MCP protocol (stdio or HTTP)
    ┌───────────┴───────────┐
    │                       │
┌───▼──────────┐   ┌────────▼──────────┐
│  Local server │   │  Remote server    │
│  (stdio)      │   │  (SSE / HTTP)     │
│  e.g. file    │   │  e.g. SaaS API    │
│  system ops   │   │  gateway          │
└──────────────┘   └───────────────────┘
```

### Key concepts

<AccordionGroup>
  <Accordion title="Tools">
    Tools are named functions exposed by an MCP server that Cline can call. Each tool has a name, a description, and a JSON Schema describing its input parameters. When Cline identifies a tool that can help with your request, it asks for your approval before calling it.

    ```json theme={null}
    {
      "name": "query_database",
      "description": "Run a read-only SQL query against the analytics database",
      "inputSchema": {
        "type": "object",
        "properties": {
          "sql": { "type": "string", "description": "The SQL query to execute" }
        },
        "required": ["sql"]
      }
    }
    ```
  </Accordion>

  <Accordion title="Resources">
    Resources expose read-only data under a URI scheme (e.g. `file:///project/readme.md` or `db://sales/schema`). Cline can reference resource content as context without executing any code. Resources are ideal for things like configuration files, database schemas, or API documentation.
  </Accordion>

  <Accordion title="MCP hosts and clients">
    An **MCP host** is the application that embeds a model — in this case, the Cline VS Code extension or Cline CLI. The host manages server lifecycles, surfaces capabilities to the model, and enforces user-approval rules. The **client** is the protocol layer inside the host that speaks the MCP wire format to each server.
  </Accordion>

  <Accordion title="Security model">
    Each MCP server runs in its own process with its own credentials. Sensitive data (API keys, tokens) lives in the server's environment variables and is never sent to the model directly. Every tool call requires explicit user approval unless you add it to the `alwaysAllow` list in your config.
  </Accordion>
</AccordionGroup>

## What you can do with MCP

<Columns cols={2}>
  <Card title="Web services and APIs" icon="globe">
    Monitor GitHub for new issues, post to Slack, fetch real-time weather data, or call any REST or GraphQL API.
  </Card>

  <Card title="Database queries" icon="database">
    Query Postgres, MySQL, SQLite, or any database. Generate reports, analyze customer behavior, or build dashboards — all from a chat message.
  </Card>

  <Card title="Browser automation" icon="browser">
    Automate web testing, scrape e-commerce sites for price data, or take screenshots for visual regression checks.
  </Card>

  <Card title="File system operations" icon="folder">
    Read and write local files, generate documentation from source code, or keep README files in sync with your project.
  </Card>

  <Card title="Project management" icon="list-checks">
    Create Jira tickets from code commits, generate weekly progress reports, or sync tasks across tools like Linear and Notion.
  </Card>

  <Card title="Codebase intelligence" icon="search-code">
    Generate API docs from code comments, create architecture diagrams, or perform semantic search across a large monorepo.
  </Card>
</Columns>

### Example: chaining multiple servers

Cline can use tools from several MCP servers in a single conversation. For example:

1. The **GitHub MCP server** fetches a list of open pull requests.
2. The **database server** queries metrics for the affected code paths.
3. The **Notion server** creates a formatted review report with those metrics attached.

You describe the task once; Cline orchestrates the tool calls.

## How Cline integrates MCP

### Using servers

Once a server is configured, Cline automatically detects its tools. During a conversation, Cline recognises when a tool could help and suggests using it. You approve the call, Cline executes it, and the result is incorporated into the response.

You can also ask Cline directly:

> "Use the database server to show me last week's top-10 products by revenue."

### Building servers

Cline can help you build new MCP servers from scratch using natural language:

* Describe the API or service you want to wrap.
* Cline generates the boilerplate, tool definitions, and configuration.
* Paste in official API documentation for best results.
* Cline handles dependencies, environment variables, and the build step.

See [Building custom MCP servers](/mcp/mcp-server-development-protocol) for the full development protocol.

### CLI support

MCP servers work with both the Cline VS Code extension and the Cline CLI. If you use the CLI, configure servers under the `mcpServers` key in the CLI configuration file.

## Getting started

<Steps>
  <Step title="Find a server">
    Browse the [MCP Marketplace](/mcp/mcp-marketplace) inside Cline, or check community repositories like the [official MCP servers](https://github.com/modelcontextprotocol/servers) and [awesome-mcp-servers](https://github.com/punkpeye/awesome-mcp-servers).
  </Step>

  <Step title="Install or configure it">
    Use the one-click installer in the Marketplace, or [add the server manually](/mcp/adding-and-configuring-servers) by editing `cline_mcp_settings.json`.
  </Step>

  <Step title="Use it in chat">
    Ask Cline to use the new server's capabilities. Cline will select the right tool and prompt for approval.
  </Step>
</Steps>

## Security best practices

<Warning>
  MCP servers can execute code and access external services on your behalf. Only install servers from sources you trust, and review the tools a server exposes before enabling it.
</Warning>

* Store credentials in `env` fields in your MCP config — never hard-code them in server code.
* Use the `alwaysAllow` list sparingly; prefer reviewing each tool call until you trust a server.
* Restrict server permissions to only the resources they need (e.g., read-only database roles).
* Validate all inputs inside your server code to guard against injection attacks.
* For SSE/remote servers, use HTTPS and token-based authentication.

## External resources

* [Official MCP servers on GitHub](https://github.com/modelcontextprotocol/servers)
* [Awesome MCP servers (community list)](https://github.com/punkpeye/awesome-mcp-servers)
* [mcpservers.org directory](https://mcpservers.org/)
* [mcp.so directory](https://mcp.so/)
* [glama.ai MCP server listing](https://glama.ai/mcp/servers)
* [PulseMCP](https://www.pulsemcp.com/)