Import Your Claude Desktop & Cursor MCP Config Into a Tester in 30 Seconds

Table of Contents

• Why test outside your MCP client?
• Where each client keeps its MCP config
• mcpServers vs servers: the format differences
• Import every server in one click
• Paste a config instead
• What gets imported, and what doesn't
• After the import: find out why a server fails
• FAQ

Why test outside your MCP client?

A server shows a red dot in Claude Desktop. Or Cursor lists it with zero tools. The client tells you almost nothing about why.

A tester shows you everything: the exact command it ran, every JSON-RPC message, and the server's own stderr output. That's usually enough to spot the problem in a minute.

The annoying part is setup. You already typed the command, arguments and API keys once. Typing them again into another tool is slow, and a typo gives you a different bug from the one you're chasing.

So start from the config file you already have. This guide shows where each client keeps it, then how to import it in one step.

Where each client keeps its MCP config

These are the user-level files each client reads. On Windows, %APPDATA% is usually C:\Users\YOU\AppData\Roaming.

Some clients also read a project-level file from the folder you have open: .cursor/mcp.json in Cursor, .vscode/mcp.json in VS Code and .mcp.json in Claude Code. If a server only exists in one of those, you'll paste it in later.

Quick way to open the Claude Desktop file: Settings → Developer → Edit Config. My Claude Desktop MCP setup guide and Cursor MCP guide cover each client in more depth, and the MCP config files guide covers other clients.

mcpServers vs servers: the format differences

A local (stdio) server in Claude Desktop, Cursor or Windsurf looks like this:

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

A remote server swaps command for url, often with a header for the API key:

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": { "Authorization": "Bearer YOUR_TOKEN" }
    }
  }
}

VS Code uses a servers key and usually adds a type:

{
  "servers": {
    "filesystem": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/Documents"]
    }
  }
}

The fields inside each entry are the same idea everywhere: command, args, env and sometimes cwd for local servers; url and headers for remote ones. That's why one importer can read all of them.

Import every server in one click

MCP Playground Desktop reads all five user-level files above. Here's the whole flow:

1. Open the import screen. In the Tester, click + More servers & import from Claude, Cursor… in the sidebar. In Agent Studio, click Import. Both open Add a server on the Import tab.
2. Wait a moment while it scans. You'll see "Looking for MCP configs on this computer…", then your servers grouped by client.
3. Pick the servers. Everything new is ticked already. Servers you've imported before show already added and can't be ticked, so you won't get duplicates.
4. Click Import N servers. They're saved on your computer and show up in both the Tester and Agent Studio.

Each row shows the command and arguments (or the URL) it found. If an entry carried secrets, it also says something like 2 env vars · bearer token copied too, stored encrypted.

Below the list, the app tells you which clients it didn't find, for example "Not installed or no config: Windsurf, Claude Code". If a file exists but has a JSON error, you'll see a red "Couldn't read this file (invalid JSON?)" next to that client. That's worth fixing anyway: the client itself can't read that file either.

That's the 30 seconds. Click a server, click Connect, and you're looking at its tools.

Paste a config instead

For a project-level file, a README snippet or a config a teammate sent you, use the Paste a config box on the same tab, then click Find servers. It accepts:

• A full file with mcpServers or servers
• Just the inner map: { "name": { "command": … } }
• A single entry: { "command": "npx", "args": […] } or { "url": "…" }
• A fragment copied out of a bigger file: "name": { … }

If the text doesn't parse, you'll see That isn't valid JSON. Paste a config like { "mcpServers": { … } }. If it parses but has no runnable entry, the error is No servers found. Each one needs a "command" or a "url".

What gets imported, and what doesn't

One thing to check by hand: variables. VS Code configs often use ${input:api-key}, and some Cursor configs use ${env:API_KEY}. The client fills those in when it starts the server. The importer copies them as plain text, so replace them with real values in the connection's env vars or headers before you connect.

Imported commands don't run straight away. The first time you connect a stdio server, the app shows Run a local command? with the exact command, folder and any risky environment variables. A config file can contain anything, so you approve each command once. It asks again if the command, arguments, folder or env var names change.

Your original config files are only read, never changed. Claude Desktop and Cursor keep working exactly as before.

After the import: find out why a server fails

This is where it pays off. The app runs the server with your real login-shell PATH on a Mac, so a command that works in Terminal runs here too. If it doesn't start, you get a plain answer instead of a red dot:

• "Couldn't find "uvx" on this computer." with how to install it. That's the cause behind most spawn npx ENOENT errors.
• "The working directory doesn't exist" when a cwd points at a folder you've moved.
• The Server stderr tab when the process started and then crashed. Your stack trace is there.

If the server works in the app but still fails in Claude Desktop, the difference is the client's environment. My guide to servers that work in the terminal but not in Claude Desktop walks through the six usual causes.

Get MCP Playground Desktop for Mac and Windows →

Only have remote servers? You don't need the desktop app for those. Test any HTTPS MCP server free in your browser →

FAQ

Conclusion

Your MCP servers are already written down in a JSON file. Import that file instead of retyping it, and you're testing the exact command your client runs, with its real env vars, in under a minute.

When a server misbehaves, that's the fastest way to see why. Get MCP Playground Desktop for Mac and Windows →