How to Install and Use an MCP Server with an AI Coding Assistant

Adding an MCP server to your AI coding assistant lets the model reach things it otherwise cannot: your issue tracker, a database, documentation, a browser, or files outside the current project. The process is similar across clients, but the exact file names and keys differ. This guide gives you the general steps and points out where clients diverge.

If you need a refresher on what MCP is, start with What Is MCP (Model Context Protocol).

Note: Client configuration formats change over time. Treat the examples below as the general shape, and always check your client’s current documentation for exact file locations and keys.

Step 1: Pick a server and read its README

Before installing anything, answer three questions:

1. Who maintains it? Prefer official servers published by the vendor of the system you are connecting, or well-maintained open-source projects with recent activity.
2. What does it access? Read the list of tools. A server that only reads is lower risk than one that can write, delete, or send.
3. How does it run? Local (stdio, launched as a subprocess on your machine) or remote (an HTTP endpoint you connect to)?

A good README tells you the launch command, the required environment variables, and any scopes or permissions the server needs.

Step 2: Install the prerequisites

Local servers are usually distributed as packages and launched with a runner:

• Node.js servers are commonly run with npx, which downloads and runs the package. You need a recent Node.js LTS installed.
• Python servers are often run with uvx (from the uv tool) or pipx.
• Docker images are another common option, especially for servers with heavier dependencies.

Check that the runner works in a terminal first:

node --version
npx --version
# or, for Python servers
uv --version

A frequent source of trouble: GUI applications may not inherit the same PATH as your shell. If the client cannot find npx or uvx, use the absolute path to the executable in your config (find it with which npx).

Step 3: Add the server to your client’s config

Most clients use a JSON file with an object that maps a server name to its launch details. Here is the typical shape for a local stdio server, using the reference filesystem server as an example:

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

And a server that needs a secret, passed as an environment variable:

{
  "mcpServers": {
    "my-tracker": {
      "command": "npx",
      "args": ["-y", "example-tracker-mcp"],
      "env": { "TRACKER_API_TOKEN": "<your token>" }
    }
  }
}

(example-tracker-mcp is a placeholder name, not a real package.)

Where configs differ between clients

Aspect	What varies
File location	Some clients use a global config in your user directory, others a project file such as .cursor/mcp.json or .vscode/mcp.json, and many support both
Top-level key	Commonly mcpServers; some clients use a different key, for example servers in VS Code
Adding servers	Some clients offer a CLI command or settings UI instead of hand-editing JSON. For example, Claude Code has claude mcp add
Remote servers	Usually configured with a url field (and sometimes a type such as http) instead of command and args
Secrets	Some clients support variable substitution or input prompts so tokens are not stored in plain text

A command-line example, for clients that support one:

# Claude Code: add a local stdio server (everything after -- is the launch command)
claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem /path/to/folder

Remote servers

Remote servers run as a hosted HTTP service. Instead of a command, you give the client a URL. Many remote servers use OAuth: the first time you connect, the client opens a browser window where you sign in and approve access. This avoids storing long-lived tokens on disk and lets you revoke access from the service’s settings page.

Step 4: Restart or reload the client

Most clients read MCP configuration at startup or when you trigger a reload. After saving the config:

• Fully quit and reopen desktop apps (closing the window may not be enough).
• In IDEs, look for an MCP panel or command palette entry to restart servers.
• In CLI tools, start a new session.

Then check the client’s MCP status view. You should see the server listed with a connected status and a list of tools.

Step 5: Use it, and approve tool calls deliberately

You usually do not need to name the server. Describe the task, and the model will pick a relevant tool:

• “List the open issues labeled bug and summarize the three oldest.”
• “Read the schema of the orders table and write a query for last week’s refunds.”

Most clients ask for approval before running a tool. Read the tool name and arguments before you click approve. Some clients let you always allow specific tools; reserve that for read-only tools you trust.

Step 6: Test the server outside your client (optional but useful)

The MCP project provides an Inspector, a developer tool for connecting to a server directly, listing its tools, and calling them by hand:

npx @modelcontextprotocol/inspector npx -y @modelcontextprotocol/server-filesystem /path/to/folder

If a server works in the Inspector but not in your client, the problem is almost always client configuration: path, environment variables, or the config key.

Troubleshooting checklist

• Server does not appear. Check that the JSON is valid (a trailing comma is enough to break it) and that you used the key your client expects.
• “Command not found.” Use absolute paths for npx, uvx, node, or docker.
• Server starts then disconnects. Check the client’s MCP logs. Missing environment variables and expired tokens are the usual culprits.
• Tools appear but fail. Verify the token’s scopes and that the server can reach the target system (VPN, firewall, proxy).
• Too many tools. Some clients degrade when dozens of tools are loaded at once. Disable servers you are not using in the current project.
• Server writes to stdout. For stdio servers, anything printed to stdout that is not protocol traffic can corrupt the connection. If you are writing your own server, log to stderr.

Keep it safe

Every server you add expands what the model can do, and what a manipulated model could do. Before connecting a server to anything important, run through our security checklist for AI agents. The short version: least privilege, scoped tokens, approval for writes, and caution with any server that reads untrusted content.

Finding good servers

The hardest part is often choosing. Search results mix official servers, active community projects, and abandoned experiments. AgentZone is being built as a curated directory with setup notes and client compatibility for each entry, organized by category. It is launching soon.