Connect an MCP Server in Five Minutes

By the end of this guide your AI assistant will read the contents of a real folder and answer questions from it — not from training data, but from live files. The setup takes about five minutes. The only part competitors gloss over is scope: grant too wide a path and you’ve handed a language model your entire machine.

The fastest correct path is the official filesystem server, pointed at exactly one folder. Get that loop working first. Everything else — GitHub, Slack, Postgres — is the same pattern repeated.

What you need before you start

• An MCP-capable host. A desktop AI assistant or a code editor with MCP support. Check its settings for an “MCP” or “Connectors” section — if it’s there, you’re good.
• Node.js on your PATH. Most MCP reference servers are distributed as npm packages and launched with npx. Confirm you have it:

node --version

If that errors, install Node.js from nodejs.org before continuing. Nothing else here will work without it.

• One folder you want to expose. A notes folder, a project directory — something specific and bounded. Do not use ~ or /. That is the mistake that bites people.

Step 1 — Locate your host’s MCP config file

MCP hosts launch servers they find in a small JSON config file. The file location varies by app; look for an “Edit config” link or button in the MCP/connectors settings panel — most hosts surface this directly in the UI.

The shape is always the same: a top-level mcpServers object, with one keyed entry per server. According to the MCP getting-started docs, each entry tells the host what command to run to start that server. Open the file in any text editor.

If your host has no existing mcpServers key yet, the file might be an empty {} or contain other settings — either way, add the key at the top level.

Step 2 — Add the filesystem server with a scoped path

Paste this into your config, replacing the path with a real folder:

{
  "mcpServers": {
    "files": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/notes"]
    }
  }
}

The -y flag tells npx to install the package automatically if it isn’t cached — no separate install step needed. The path at the end is the only folder the server can touch. Change /Users/me/notes to your actual folder path and nothing else.

Why scope matters here. The filesystem server exposes every read and write tool on the path you give it. Point it at your home directory and the model can reach your SSH keys, your dotfiles, your browser cookies — anything accessible on that path.

Point it at /Users/me/notes and the blast radius of any mistake is that one folder. Scope is the only meaningful safety control this config gives you, and it costs nothing to use it.

Step 3 — Restart and confirm the handshake

Save the config file and restart your host (or use whatever “reload connectors” option it exposes). On restart, the host runs a short capability handshake: it launches each server process, exchanges protocol versions, and the server declares the tools and resources it offers. If the filesystem server started successfully, you’ll see it listed in the connected servers panel — typically with tools like read_file, list_directory, and write_file.

If no server appears after restarting, the most common cause is that npx isn’t on the PATH the host uses to launch processes. That PATH is often different from your shell’s PATH. One quick diagnostic: look at the server logs (most hosts surface these in the connectors UI). If you see command not found: npx, you need to give the host the full path to npx:

which npx

Then set "command" in your config to that absolute path, e.g., /usr/local/bin/npx.

Step 4 — Smoke-test with a real prompt

Don’t ask a generic question. Ask something that can only be answered by reading the folder:

“List the files in my notes folder and summarise the most recent one.”

The assistant should call list_directory, then read_file, then answer from the actual file contents — not from training data. If it does, the server is live and the tool loop is working.

If the assistant answers without using a tool — or says it can’t access files — it either hasn’t reloaded the server yet, or the prompt isn’t specific enough to trigger tool use. Try being more explicit: “Use the files tool to list what’s in /Users/me/notes.”

What’s actually happening during that exchange

When the model wants to use a tool, it emits a structured tool-use request. The host intercepts it, routes it to the right server process, the server performs the operation and returns a structured result, and the model reads that result and continues generating. You never see this exchange directly — it looks like the assistant just knows things — but understanding it matters for two practical reasons.

First, the server is a separate process. If it crashes, the host doesn’t crash with it. You can restart servers independently, and most hosts will show a server as “disconnected” if its process dies so you know something is wrong.

Second, tool calls are visible in most hosts’ debug or activity logs. When something behaves unexpectedly — the assistant claims it read a file it couldn’t have — check the logs. You’ll see exactly which tools were called with which arguments.

The Anthropic MCP announcement describes the protocol’s design goal: one standard interface that the same server implementation can serve to any MCP-capable host. Set up a GitHub server once and it works in your editor, your terminal agent, and your chat assistant without reconfiguration. If you want the full picture of how hosts, clients, and servers relate, the MCP explainer walks through the architecture from scratch.

Adding a service server — GitHub as the example

Once the filesystem server is working, adding a service server is the same config pattern. For GitHub:

{
  "mcpServers": {
    "files": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/notes"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "your-scoped-token" }
    }
  }
}

The credential pattern is universal: service servers take secrets via environment variables in the env object. What changes per server is which variables it expects — check that server’s README.

Scope the token the same way you scoped the path. Create a fine-grained GitHub token with read-only access to the specific repos you want the assistant to query, not a full-access personal access token. If the assistant can create and delete repos, so can any prompt that misdirects it. Minimal permissions are your second line of defense after the filesystem path constraint.

Once the GitHub server is connected and your host is restarted, you can ask things like “Summarise the open issues labelled bug in my main repo” and get answers from live repository data.

Troubleshooting

“Failed to start” or server never appears

• Confirm node --version works in a terminal, then check whether the host’s server-start logs show command not found. If they do, set "command" to the absolute path of npx.
• Make sure you saved the config file before restarting the host.

The assistant responds but doesn’t use a tool

• Verify the host has restarted and the server shows as connected.
• Rephrase the prompt to be explicit about what the tool should do. Some hosts require tool use to be clearly implied by the request.

Path or permission errors from the filesystem server

• Confirm the folder path exists exactly as written. JSON paths are case-sensitive on macOS and Linux.
• On Windows, escape backslashes (\\) or use forward slashes — both work in JSON path strings.

Auth errors from a service server

• The environment variable name is almost certainly wrong or missing. Re-read the server’s README carefully; some servers use non-obvious variable names.
• Confirm the token itself is valid and has the required scopes by testing it with curl outside the assistant first.

Prompt-injection risk with web-facing servers

This one doesn’t have a clean troubleshooting fix — it’s a design decision. If your host has both a powerful tool (write to filesystem, post to Slack) and a web-fetch or email-reading server, untrusted content the assistant reads can include instructions that try to redirect those tool calls.

The MCP spec doesn’t solve this for you. The practical mitigation is to keep high-privilege servers and untrusted-content servers in separate host configurations — or at minimum, run the assistant at read-only permissions when processing external input.

Deciding what to connect next

The right order is not “most powerful first.” It’s “most useful for a specific task, narrowest scope possible.”

Filesystem (one project folder) — where everyone should start. Once you have this working for one folder, you understand the config and can replicate it.

Your version control host (read-only token) — the jump from “talks about code” to “reads your actual issues and PRs” is immediate and high-value. This is also where MCP starts to resemble the tool-calling loops that power AI agents — it’s the same mechanism, just surfaced through your assistant’s UI.

A read-only database connection — a Postgres server with read-only credentials lets you ask plain-language questions about your own data. The read-only constraint is load-bearing: it means a misdirected query can return data but cannot modify or delete rows.

Web fetch / search — genuinely useful for current information, but carries the highest prompt-injection risk. Add these last, and consider keeping them in a separate host profile from your write-capable servers.

Add them one at a time, confirm each is working and scoped correctly before proceeding. The discipline is practical: if something behaves unexpectedly, you want to know which server is involved without having to bisect four simultaneous additions.

Maintenance habits

Two habits that take five minutes each and prevent slow-building problems.

First, periodically audit your connected servers. Every server is a standing grant of access. Servers you added six months ago for a project that’s done are still running every time your host starts. Remove them.

Second, review token scopes when you rotate credentials. It’s easy to replace a read-only token with a full-access one when the old one expires. Check the scopes every time — it takes 30 seconds and it’s the most common way well-intentioned setups quietly lose their safety margins.

FAQ

Does MCP work with all AI assistants?

No — your assistant must explicitly support the Model Context Protocol. As of mid-2026, Claude Desktop, Cursor, Zed, and several other editors and agent frameworks do. Check your assistant’s settings for an “MCP” or “Connectors” panel. If it isn’t there, the host doesn’t support it yet.

Do I need to write code to use an MCP server?

Not to use existing servers. The config is JSON, and the servers themselves are distributed as packages you run with npx. You only write code if you’re building a custom server. For a deeper look at how the protocol primitives fit together — tools, resources, and prompts — see the MCP explainer on open-source AI tools.

Can I run multiple MCP servers at the same time?

Yes. Each server is a separate entry under mcpServers and runs as its own process. Most hosts handle five or ten servers without issue. The practical limit is how many grants of access you actually want active simultaneously — not a technical one.

What’s the difference between a tool, a resource, and a prompt?

Tools are callable functions (read a file, query a database, post a message). Resources are data the server can expose for the model to reference. Prompts are pre-written templates the server advertises. For a first setup, tools are what matter — the filesystem server is almost entirely tools.

Is it safe to give the MCP server write access to my filesystem?

Only with a tightly scoped path. Write access to /Users/me/one-project-folder is a reasonable setup if you want the assistant to create or edit files there. Write access to your home directory is not. The scope you pass in the args array is the entire safety boundary; don’t widen it beyond what the task requires.

Before you close this tab

Quick checklist:

• [ ] node --version works in your terminal
• [ ] You found your host’s MCP config file
• [ ] Filesystem server added, scoped to one specific folder (not ~ or /)
• [ ] Host restarted; server shows as connected
• [ ] A real prompt triggered a tool call and returned live file contents
• [ ] Any service server tokens use minimum required permissions
• [ ] Credentials are in the env object, not written inline in the config

The verdict

Connecting an MCP server is genuinely a five-minute job. Drop a few lines into your host’s JSON config, point a filesystem server at one folder, restart, and test with a prompt that requires the tool. Done.

The skill that actually matters is what you do with scope. Grant the narrowest access that does the job. Keep untrusted-content servers away from write-capable ones. Add servers one at a time so you always know what each one can reach. That discipline is the difference between an assistant that’s genuinely useful and one that’s quietly overprivileged. Start narrow, confirm the loop, then expand deliberately.

Last verified June 13, 2026 against the MCP getting-started docs and the Anthropic MCP announcement.