MCP overview

Model Context Protocol, or MCP, is a standard way for AI clients to connect to external tools and data sources. An MCP client might be Claude Desktop, Claude Code, Cline, Cursor, or another compatible agent. An MCP server is a local or remote program that exposes tools to that client.

The simplest example is a filesystem server. It lets the AI client read, write, search, and organize files in directories you explicitly allow.

That power is useful. It is also risky. A badly scoped MCP server can expose private files, credentials, databases, or write access that the AI should not have.

Client vs server

The client is the AI application you interact with.

Examples:

  • Claude Desktop
  • Claude Code
  • Cline
  • Cursor
  • VS Code-based agents

The server is the tool provider.

Examples:

  • Filesystem server
  • Git server
  • SQLite server
  • Postgres server
  • Fetch server
  • Memory server
  • Internal API server

The client starts or connects to the server. The server exposes tools. The model asks to use those tools. You approve or deny the action depending on the client.

Step-by-step setup

Quick requirements

Prepare:

  • An MCP-compatible client
  • Node.js and npm for npx-based servers
  • Python or uv for Python-based servers
  • Absolute paths to any folders or databases you want to expose
  • A small test directory
  • A clear security boundary

Check Node:

node --version
npm --version

Many MCP setup failures are not protocol problems. They are path, JSON, runtime, or permission problems.

Step 1: Choose one safe first server

Start with the filesystem server and a harmless test folder.

Create a folder:

mkdir mcp-test

Put a simple file inside it. Then expose only that folder in the MCP configuration. Do not start by exposing your whole home directory.

Good first folders:

  • A test folder
  • A project docs folder
  • A copied sample repository
  • A non-sensitive scratch directory

Bad first folders:

  • Your home directory
  • Desktop with personal files
  • Downloads with unknown files
  • Password manager exports
  • SSH folders
  • Cloud sync folders with private data
  • Production databases

Step 2: Configure Claude Desktop

Open Claude Desktop settings, go to Developer settings, and choose Edit Config.

The config file is typically:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

Add a filesystem server:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/absolute/path/to/mcp-test"
      ]
    }
  }
}

Use an absolute path. Relative paths are a common reason MCP servers fail.

Save the file, fully quit Claude Desktop, and reopen it. The server must restart with the app.

Step 3: Configure Windows paths correctly

On Windows, use escaped backslashes in JSON:

{
  "mcpServers": {
    "filesystem": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "C:\\Users\\YourName\\mcp-test"
      ]
    }
  }
}

The cmd /c npx wrapper can help when a desktop app cannot find npx directly.

If a server needs environment variables, add an env object:

{
  "mcpServers": {
    "example": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "example-mcp-server"],
      "env": {
        "EXAMPLE_API_KEY": "paste-key-here"
      }
    }
  }
}

For sensitive credentials, use the most secure secret mechanism your client supports. Do not paste production secrets into random community server configs unless you trust the server.

Step 4: Configure Cline

Cline can add MCP servers through its UI or config.

In Cline:

  1. Open the Cline panel.
  2. Click the MCP Servers icon.
  3. Use Marketplace if available.
  4. Or open the Configure tab.
  5. Click Configure MCP Servers.
  6. Add entries under mcpServers.
  7. Save and reload.
  8. Verify tools appear.

For Cline CLI, the config can live at:

~/.cline/mcp.json

For Cline IDE extensions, use the UI button so you edit the active config file for that extension.

Verify it works

Step 5: Test one tool call

After restarting the client, ask for something safe:

List the files in the mcp-test folder. Do not modify anything.

Then test one write action:

Create a file named hello.txt in the mcp-test folder with one sentence inside it.

Review the approval prompt carefully. If the client shows the proposed tool call, inspect the target path before approving.

Step 6: Add more servers only when needed

The official MCP reference server repository includes small reference implementations such as filesystem, Git, memory, fetch, sequential thinking, time, and others. Treat reference servers as examples and evaluate any server before using it on sensitive data.

Popular categories include:

  • Filesystem access
  • Git repository operations
  • SQLite or Postgres inspection
  • Web fetching
  • Documentation search
  • Memory
  • SaaS API connectors
  • Internal tools

Add one server at a time. Test it before adding another. When several servers fail at once, debugging becomes slow.

Step 7: Local STDIO vs remote HTTP/SSE

Local STDIO servers are started by the client as local processes. They usually use:

{
  "command": "npx",
  "args": ["-y", "some-mcp-server"]
}

Remote servers are reached through a URL and may use HTTP or SSE depending on the client.

For a first local setup, prefer STDIO. It is easier to reason about because the server runs on your machine under your user account.

Use remote servers only when:

  • You trust the server.
  • You understand authentication.
  • You know what data will be sent.
  • The client supports the transport you choose.
  • You have a reason not to run locally.

Common problems

The MCP server does not appear

Check:

  • The JSON is valid.
  • The server is under mcpServers.
  • Paths are absolute.
  • Node or Python is installed.
  • The command works in a terminal.
  • The client was fully restarted.

For Claude Desktop logs:

macOS: ~/Library/Logs/Claude
Windows: %APPDATA%\Claude\logs

Look for mcp.log and mcp-server-SERVERNAME.log.

npx is not found

Use the full path to npx, or on Windows use:

"command": "cmd",
"args": ["/c", "npx", "-y", "@modelcontextprotocol/server-filesystem", "C:\\Users\\YourName\\mcp-test"]

Then restart the client.

JSON errors break everything

Validate the JSON. Common mistakes include trailing commas, unescaped backslashes on Windows, missing braces, and adding a second top-level object instead of merging into one mcpServers object.

The tool fails silently

Run the server command manually in a terminal. If it fails there, the MCP client is not the issue.

The server can access too much

Stop the client and narrow the paths. For filesystem access, expose only the folders the task actually needs.

Security rules for local MCP

Use these rules:

  • Start with a scratch folder.
  • Grant the smallest directory access possible.
  • Avoid home-directory access.
  • Avoid secrets folders.
  • Avoid production databases.
  • Read tool approval prompts carefully.
  • Prefer read-only database users.
  • Keep API tokens scoped and revocable.
  • Remove servers you no longer use.
  • Audit config files after experiments.

MCP does not remove responsibility. It standardizes tool access. You still decide what tools and data an agent can reach.

Questions to ask before installing

  • What action should the MCP server be allowed to do, and what should it never do?
  • Which exact files, folders, and APIs should be exposed on day one?
  • Will this server run local commands or only read-only tools?
  • Do you need a local model and client that stays on-device, or are you adding a managed provider?
  • Do you have a clean rollback plan before first-run, and is someone available to review tool calls?
  • What is your policy if a local agent starts modifying critical files automatically?

Approximate U.S. planning cost

MCP server local setup is usually mostly a time cost first.

  • Software and install cost: mostly free and open-source for local setup, including local runtimes and server implementations.
  • Local hardware cost: depends on what your server does. A local filesystem server is lightweight. Adding tools like browsers or embedding models can require more memory and storage.
  • API token spend: only applies when MCP servers call cloud services such as OpenAI, Anthropic, Azure, or similar providers. Token costs are usage-based.
  • Paid platform plans: some clients and hosting models may use paid plans for enterprise features, seat controls, or managed hosting.
  • VPS or managed services: useful when you want multi-device access, hardened hosting, or team sharing; these are ongoing operational costs (compute, storage, bandwidth).

Use current pricing pages for live numbers:

  • OpenAI API: https://platform.openai.com/docs/pricing
  • Anthropic usage plans: https://www.anthropic.com/pricing
  • Ollama local mode for offline operation: https://docs.ollama.com/faq
  • Open Interpreter local providers (if used by MCP tools): https://docs.openinterpreter.com/guides/running-locally
  • MCP security requirements: https://modelcontextprotocol.io/community/seps/1024-mcp-client-security-requirements-for-local-server-installation/

Cost breakdown

  • One-time cost: local hardware, data transfer during model/tool downloads, and setup time.
  • Recurring cost: API tokens for cloud LLM/API usage, cloud hosting if any, optional managed enterprise plans, and storage growth.
  • Soft cost: accidental misconfiguration, broad scopes, or weak change review processes.

Trust boundaries

Treat MCP as four trust zones:

  • Zone A: Agent: model and prompt behavior.
  • Zone B: MCP server process: what gets executed and what can be read/written.
  • Zone C: Runtime: Node/Python environments, package registry access, network permissions.
  • Zone D: External providers: model APIs, web fetchers, and third-party databases.

Minimize trust in each zone; prefer one zone change per change window and test after each server add.

Workspace and file-system permissions

  • Expose only narrow absolute paths at first.
  • Prefer read-only directories for analysis tasks.
  • Use separate workspaces for experiments and sensitive repositories.
  • Keep source and secrets out of directories that a server could reach by default.
  • If a server is no longer needed, remove its path and restart the client.

Key and secret management

  • Keep API keys out of mcpServers JSON blocks.
  • Store secrets in environment variables or a dedicated secret store supported by the client.
  • Rotate provider keys after onboarding, after shared access, and on role changes.
  • Use one key per tool integration, and disable unused keys immediately.

Red flags

  • A JSON block that points to unknown shell scripts or binary URLs.
  • npx or command values that are not pinned or versioned.
  • File permissions that include home directories by default.
  • No ability to review or deny every tool call.
  • A model provider token that has broad permissions not needed by the task.

Rollback and update guidance

Rollback (local misstep):

  1. Remove the MCP server block from config.
  2. Save and restart the client.
  3. Check logs and rerun a harmless test tool call.

Update safety:

  • Update one of: client, package, or server at a time.
  • Read release notes for breaking changes before upgrading package versions.
  • Re-test with the mcp-test folder before adding broader paths again.

Bottom line

Install MCP servers one at a time, use a minimal mcpServers JSON config, restart the client, and test with a harmless folder first. The best local MCP setup is not the one with the most servers. It is the one with the smallest safe permissions that still solves the task.