Your AI assistant - Claude, GitHub Copilot, Cursor, whichever one you use - knows a lot about programming, writing, and the internet as it existed at training time. It does not know what is in your project folder. It cannot read your Postgres database. It cannot look at your GitHub issues. It cannot see your Slack threads. Until you tell it how.

MCP - the Model Context Protocol - is how you tell it. It is the open standard that lets any AI assistant talk to any tool, file system, database, or API. Anthropic introduced it in late 2024 and it has since been adopted by Microsoft, Cursor, Codeium, OpenAI, AWS, and most of the AI tooling community. If you have heard the term tossed around without quite knowing what to do with it, this is the 10-minute version.

We will skip the protocol theory until after you have a working example. By the end of step 5, your AI assistant will be reading files on your machine. Then we will explain what just happened, what else you can connect, and what to do when editing JSON config by hand stops scaling.

A 10-minute walkthrough

We are using Claude Desktop because it has the cleanest first contact with MCP - graphical install, no terminal, sensible defaults. Everything in this section also works in Cursor, VS Code with GitHub Copilot, Windsurf, Cline, Amazon Q Developer, and most other MCP-aware AI clients. Only the config file path differs; the snippet you paste is the same. There is a per-client map at the end of this article.

The example: we are going to give your AI assistant the ability to read files in a folder on your machine.

1. Install Claude Desktop

Download from claude.ai/download. Install it like any other desktop app and sign in. You also need Node.js installed - if you do not have it, grab it from nodejs.org first. Most MCP servers ship as npm packages.

2. Find the config file

This is the file Claude Desktop reads on startup to decide which MCP servers to launch.

If the file does not exist yet, create it. It is plain JSON.

3. Paste this

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/yourname/Documents"
      ]
    }
  }
}

Replace /Users/yourname/Documents with whatever folder you want your assistant to be able to read. Pick something with a few interesting files in it.

That npx -y @modelcontextprotocol/server-filesystem ... line tells Claude Desktop to download and run the official filesystem MCP server, scoped to that one folder. The -y flag auto-accepts npm’s “do you want to install this package” prompt, so the server starts without manual intervention.

On native Windows (not WSL), wrap the command in cmd /c or the spawn fails silently. This trips up a lot of people:

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

4. Restart Claude Desktop completely

Do not just close the window. Quit the app fully (Cmd+Q on macOS, right-click the system tray icon → Exit on Windows) and reopen it. MCP servers only get loaded on a fresh launch - closing the window leaves the process running and the new config sitting unread.

5. Try it

Open a new conversation and ask: “What files are in the folder I gave you access to?”

Claude should answer with an actual list of your files. Not a description of what it would do if it could see them - actual filenames. If you ask a follow-up like “summarize the most recent one,” it will read the file and answer.

If it does not work, look for an error indicator on the connectors menu in Claude Desktop, or check the MCP log file at ~/Library/Logs/Claude/mcp-server-filesystem.log on macOS or %APPDATA%\Claude\Logs\ on Windows. Most failures are missing Node.js, a typo in the folder path, or - on Windows - the missing cmd /c wrapper.

What just happened

You installed an MCP server. Three concepts are doing the work:

When you opened a new conversation, Claude Desktop launched the filesystem server as a background process, asked it “what tools do you have?”, and added those tools to the model’s available toolkit. When you asked your question, the model decided to call list_directory, the server returned the list, and Claude phrased the answer.

Filesystem is the simplest example. There are pre-built MCP servers for GitHub, Slack, Postgres, SQLite, Google Drive, AWS, Sentry, Linear, Stripe, Notion, Figma, Playwright, your own internal APIs - dozens of them on npm and PyPI today, with more shipping every week. You install each one the same way: paste a config block, restart, ask the model to use the new capability.

Same server, different client

The config block you just pasted works in any MCP-aware AI assistant. Only the file you put it in changes:

The server itself does not care which client is talking to it. It speaks one protocol; everyone who speaks the same protocol can use it. For the per-client config deep dive - scopes, override behavior, environment variable syntax differences - we have a complete config reference here.

Why MCP matters

Before MCP, every AI app needed custom code for every tool. If Cursor wanted to read your GitHub issues, Cursor’s engineers had to write a GitHub integration. If Claude wanted to do the same thing, Anthropic had to write their own. Multiply across N apps and M tools and every integration gets written N times. The math does not work, so most things never get integrated.

MCP fixes the N×M problem with one shared protocol. Write a server once and it works in every client. Build a client once and it can talk to every server. Anthropic published the spec in November 2024; within months Microsoft (VS Code), Cursor, Codeium (Windsurf), Cline, Amazon (Q Developer), Continue, and most major AI tools shipped support. OpenAI followed in 2025. It is the de facto standard.

In practice that means: when someone publishes an MCP server for the thing you care about, it works in your assistant whether or not you happen to use the same brand they used to build it. Pick a client because you like the client; pick servers because they connect to the things you work with. The two decisions are independent. That is new.

Three things to try next

You have one server working. Here are three more, each with a real-world payoff.

Connect to GitHub

{
  "github": {
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-github"],
    "env": { "GITHUB_TOKEN": "ghp_yourtoken..." }
  }
}

Now your assistant can read repos, search code across your org, list and triage issues, open PRs, and comment on threads. Generate a personal access token at github.com/settings/tokens. Scope it tightly - an MCP server with full repo write access can do a lot of damage if you ask the wrong thing.

Connect to a Postgres database

{
  "postgres": {
    "command": "npx",
    "args": [
      "-y",
      "@modelcontextprotocol/server-postgres",
      "postgresql://user:pass@host:5432/dbname"
    ]
  }
}

Now your assistant can query the database directly. “How many users signed up last week?” gets answered with a real query against real data, not a polite refusal. Point it at a read-replica or a dev database the first few times so a stray query cannot do harm.

Find more servers

The official MCP server registry lists hundreds; community “awesome-mcp” lists on GitHub catalog even more. Most are ten lines of config to install. Some highlights people install early: filesystem (the one you just used), GitHub, Postgres or SQLite, Slack, Google Drive, fetch (lets the assistant fetch arbitrary URLs), and Puppeteer or Playwright (lets it drive a real browser).

When this gets harder than it should be

Three servers in your config is fine. Ten is not. The point where most people start hating their setup is around server number five - when each new addition means:

Two patterns help. The first is hosting MCP servers yourself somewhere reachable - a small VM, a Tailscale-private host, a container - and using HTTP transport instead of stdio. That moves the runtime out of every developer’s laptop and centralizes credentials.

The second is using an orchestrator that manages the catalog and credentials for you. mcp.hosting is one: you add servers in a web dashboard, install one MCP entry into your client, and it routes everything through. Your config goes from a sprawling list of servers to a single line:

{
  "mcpServers": {
    "mcp.hosting": {
      "command": "npx",
      "args": ["-y", "@yawlabs/mcph"],
      "env": { "MCPH_TOKEN": "mcp_pat_..." }
    }
  }
}

Free for up to three servers, $9/month past that. The point is not that you have to use it - the point is that hand-editing JSON for every server is a phase, not the destination. There are several ways past it.

Common stumbling blocks

The five things that trip up most first-time MCP users:

  1. “Restart” means quit and relaunch. Closing the window does not reload MCP servers; the desktop app keeps running in the background. Cmd+Q on macOS, right-click tray → Exit on Windows.
  2. Windows needs cmd /c npx. Not just npx. Native Windows cannot directly spawn the npm shim, and the failure is silent.
  3. Approval prompts on first use. Project-scoped configs (Claude Code’s .mcp.json, for example) ask for approval the first time the project is opened - this is a deliberate security feature. Read what it is asking before approving.
  4. Environment variables go in the config, not your shell. Shell exports do not propagate to processes the AI client launches. Put credentials in the env block of the server config (or in a managed secret store if you have one).
  5. Servers fail silently. If a server does not show up after restart, check the client’s MCP log directory. Usually it is a missing dependency, a wrong path, or - on Windows - the cmd /c wrapper missing.

Where to go from here

If you have an internal API or data source you want your assistant to access and there is no server for it yet, write one. The TypeScript and Python SDKs live at github.com/modelcontextprotocol. A useful server is often a hundred lines of code.

That is the 10-minute version. The protocol takes about a week to fully internalize, but you have enough to build with right now.

Jeff Yaw, Yaw Labs. Follow along at tokenlimit.news for weekly notes on AI infrastructure.