The Quick Answer

Global installations make MCP servers available system-wide as CLI tools, while local installations isolate dependencies within projects. Use global for standalone CLI servers, local for project-specific implementations.

# Global installation (CLI tools)
$npm install -g @modelcontextprotocol/server-filesystem
 
# Local installation (project dependencies)
$npm install @modelcontextprotocol/server-filesystem

Global installations suit single-purpose servers accessed from anywhere. Local installations prevent version conflicts and ensure reproducible environments. Choose based on whether you need system-wide CLI access or project isolation.

Prerequisites

• Node.js 18+ or Python 3.8+ installed
• npm (comes with Node.js) or pip/pipx package managers
• Basic understanding of package managers
• Terminal/command prompt access with appropriate permissions

Installation

Install MCP servers globally when you need system-wide CLI access. The -g flag installs packages to a central location accessible from any directory.

# npm global installation
$npm install -g @modelcontextprotocol/server-memory  # Available everywhere
$npm install -g @modelcontextprotocol/server-github  # System-wide CLI tool
 
# Python global installation (use pipx for isolation)
$pipx install mcp-server-sqlite  # Isolated global install
$pip install --user mcp[cli]     # User-level global (less recommended)

Local installations keep dependencies isolated within your project directory. This approach prevents version conflicts between projects and ensures team members use identical versions.

# npm local installation
$cd my-project
$npm install @modelcontextprotocol/server-filesystem  # Installs to node_modules/
 
# Python local installation (virtual environment)
$python -m venv .venv            # Create virtual environment
$source .venv/bin/activate       # Activate it (Linux/macOS)
$pip install mcp-server-sqlite   # Install within venv

Configuration

Configuration differs significantly between global and local installations. Global servers require absolute paths, while local servers use relative paths and project-specific settings.

Global installations typically use system configuration files. For Claude Desktop, this means editing the global config with full paths:

{
  "mcpServers": {
    "filesystem": {
      "command": "mcp-server-filesystem",  // Global command available in PATH
      "args": ["--root", "/Users/username/documents"]
    },
    "memory": {
      "command": "/usr/local/bin/mcp-server-memory",  // Absolute path
      "args": []
    }
  }
}

Local installations require specifying the path to node_modules or virtual environment. This ensures the correct version loads regardless of global installations:

{
  "mcpServers": {
    "project-server": {
      "command": "node",
      "args": ["./node_modules/@modelcontextprotocol/server-filesystem/dist/index.js"],
      "env": {
        "NODE_ENV": "development"
      }
    }
  }
}

Windows systems need special attention for paths. Always use absolute paths and escape backslashes or use forward slashes:

{
  "mcpServers": {
    "windows-server": {
      "command": "C:\\Program Files\\nodejs\\node.exe",
      "args": ["C:/Users/username/project/node_modules/@modelcontextprotocol/server-memory/dist/index.js"]
    }
  }
}

Usage

Global installations excel for utility servers accessed across multiple projects. The npx command runs globally installed packages without permanent installation:

# Run globally installed server
$mcp-server-filesystem --root ~/projects
 
# Use npx for one-time execution
$npx @modelcontextprotocol/server-sequential-thinking
 
# Python global server via pipx
$mcp-server-sqlite database.db

These servers become available as system commands, making them ideal for development tools, file system access, or shared utilities across projects.

Local installations shine for project-specific servers with precise dependency management. Access them through npm scripts or direct node execution:

// package.json
{
  "scripts": {
    "mcp:filesystem": "node ./node_modules/@modelcontextprotocol/server-filesystem/dist/index.js",
    "mcp:custom": "node ./src/custom-mcp-server.js"
  }
}

# Run local server via npm script
$npm run mcp:filesystem
 
# Direct execution with node
$node ./node_modules/@modelcontextprotocol/server-filesystem/dist/index.js

Virtual environments ensure Python servers use project-specific dependencies:

# Activate virtual environment first
$source .venv/bin/activate  # Linux/macOS
$.venv\Scripts\activate     # Windows
 
# Run server with local dependencies
$python -m mcp_server_custom --config ./config.json

Common Issues

Error: "command not found" or "mcp-server-x is not recognized"

This occurs when globally installed packages aren't in your system PATH. Global npm packages install to platform-specific directories that must be accessible.

# Find npm global directory
$npm root -g  # Shows: /usr/local/lib/node_modules
 
# Add to PATH in ~/.bashrc or ~/.zshrc
$export PATH="$PATH:$(npm bin -g)"
 
# Windows: Add %APPDATA%\npm to PATH environment variable

The issue stems from package managers installing globals to directories not automatically included in PATH. Verify installation location and ensure your shell can find the executables.

Error: "Module version mismatch" or dependency conflicts

Version conflicts arise when global and local installations interfere. Different projects may require incompatible versions of the same MCP server or its dependencies.

# Check for conflicting versions
$npm list @modelcontextprotocol/sdk  # Shows all versions in tree
 
# Force specific version locally
$npm install @modelcontextprotocol/server-filesystem@1.2.3 --save-exact
 
# Use npm aliases for multiple versions
$npm install mcp-v1@npm:@modelcontextprotocol/server-filesystem@1.0.0
$npm install mcp-v2@npm:@modelcontextprotocol/server-filesystem@2.0.0

Isolation through local installations prevents these conflicts. Each project maintains its own dependency tree, ensuring version consistency.

Error: "Permission denied" or "EACCES" during global installation

Permission errors occur when installing globally without appropriate privileges. Operating systems restrict write access to system directories where global packages install.

# Bad: Using sudo (creates permission issues later)
$sudo npm install -g @modelcontextprotocol/server-filesystem
 
# Good: Configure npm to use user directory
$npm config set prefix ~/.npm-global
$export PATH=~/.npm-global/bin:$PATH
 
# Better: Use Node version manager
$nvm use 18
$npm install -g @modelcontextprotocol/server-filesystem
 
# Python: Use pipx instead of sudo pip
$pipx install mcp-server-sqlite  # Automatically handles permissions

Never use sudo with npm as it creates files owned by root, causing future permission problems. Configure npm to use user-writable directories or use version managers that handle permissions correctly.

Examples

Example 1: Multi-Project Development Environment

A development team manages multiple Node.js applications requiring different MCP server versions. They use local installations to maintain isolation:

// Project A: package.json
{
  "name": "legacy-app",
  "dependencies": {
    "@modelcontextprotocol/server-filesystem": "1.0.0",
    "@modelcontextprotocol/sdk": "0.9.0"
  },
  "scripts": {
    "mcp:start": "node ./node_modules/@modelcontextprotocol/server-filesystem/dist/index.js --config ./mcp-config.json"
  }
}

// Project B: package.json
{
  "name": "modern-app",
  "dependencies": {
    "@modelcontextprotocol/server-filesystem": "2.0.0",
    "@modelcontextprotocol/sdk": "1.0.0"
  }
}

Each project maintains its own dependency versions without conflicts. Developers switch between projects without worrying about global version mismatches. The package-lock.json ensures all team members use identical versions, eliminating "works on my machine" issues.

This approach scales to dozens of projects with different requirements. CI/CD pipelines reproduce exact environments using lock files, ensuring consistent builds across development, staging, and production.

Example 2: Personal Productivity Tools Setup

A developer uses MCP servers as personal productivity tools across all projects. They install utility servers globally for quick access:

# Install productivity servers globally
$npm install -g @modelcontextprotocol/server-memory
$npm install -g @modelcontextprotocol/server-brave-search
$pipx install mcp-server-sqlite
 
# Configure Claude Desktop for global access

// ~/.claude_desktop_config.json
{
  "mcpServers": {
    "memory": {
      "command": "mcp-server-memory",
      "args": ["--cache-size", "100"]
    },
    "search": {
      "command": "mcp-server-brave-search",
      "args": [],
      "env": {
        "BRAVE_API_KEY": "${BRAVE_API_KEY}"
      }
    },
    "sqlite": {
      "command": "mcp-server-sqlite",
      "args": ["~/Documents/notes.db"]
    }
  }
}

Global installation provides immediate access from any directory. The developer can query their notes database, search the web, or use memory features regardless of current project. Updates apply system-wide, maintaining consistent tool versions.

This setup works well for individual developers who want MCP servers as permanent development tools. The global approach simplifies configuration and ensures tools remain available across all contexts.

Example 3: Docker-Based Hybrid Approach

An organization standardizes MCP server deployment using Docker containers, combining benefits of both approaches:

# Dockerfile for custom MCP server
FROM node:18-alpine
WORKDIR /app

# Install dependencies locally within container
COPY package*.json ./
RUN npm ci --only=production

# Copy server code
COPY src/ ./src/

# Expose as global command within container
RUN npm link

CMD ["mcp-custom-server"]

# docker-compose.yml
version: '3.8'
services:
  mcp-filesystem:
    image: mcp/filesystem:latest
    volumes:
      - ./data:/data:ro
    command: ["--root", "/data"]
  
  mcp-custom:
    build: .
    environment:
      - NODE_ENV=production
    volumes:
      - ./config:/config

Containers provide isolation like local installations while offering global-style deployment. Each container bundles specific dependency versions, eliminating conflicts. Teams pull pre-built images or build from Dockerfiles, ensuring consistency.

This approach scales to enterprise deployments. Kubernetes orchestrates multiple MCP server instances, load balancing across containers. Updates roll out gradually without affecting running services. The hybrid model combines local isolation with global accessibility through container orchestration.