MCP Servers Explained: Give Your AI Editor Real Tools

An MCP server is a small program that gives your AI editor a set of actions it can take, like querying a database, reading GitHub issues, or driving a browser. MCP (Model Context Protocol) is the shared standard that lets any compatible editor talk to any such server. Without it, your AI can only write text and edit files. With it, it can look things up and do things.

That's the short version of MCP servers explained. The rest of this post covers how the pieces fit, how to add one in Cursor and Claude Code, and what to be careful about.

The three parts, in plain English

MCP has three moving parts, and the names are less confusing than they look:

• The client is your AI app: Cursor, Claude Code, VS Code, and so on.
• The server is a program that wraps some outside service and lists what it can do.
• The model reads that list and decides when a tool is worth calling.

Scalar's explainer describes the flow well. The server says what it can do, the client passes that list to the model, and the model decides when to call something. The server does the work, usually by hitting an HTTP API, and sends the result back.

The official intro compares MCP to a USB-C port for AI apps. That's accurate. You don't write custom glue for each editor and each service. You plug a server into any client that speaks the protocol.

Anthropic introduced MCP in November 2024. One source I found says it has been governed by the Agentic AI Foundation under the Linux Foundation since December 2025. You don't need that detail to use it, but it's why the same servers work across so many tools.

What a server can actually give your editor

Servers can offer three kinds of things: tools the model can call, resources the app can read, and prompts you can pick. In daily use, you mostly care about tools. Some examples:

• Browser control. The AI opens your app, clicks around, and reports what broke.
• Docs lookup. It reads current library docs instead of guessing from stale training data.
• Database access. It inspects your schema and runs queries.
• Issue trackers and repos. It reads tickets and pull requests, then works from them.
• Error monitoring. It pulls the real stack trace instead of you pasting it.

The practical win is fewer copy-paste trips. You stop being the courier between your tools and your AI.

Local vs. remote servers

You'll see two styles in setup instructions. A local server runs as a process on your machine, often launched with npx. A remote server lives at a URL, and you usually sign in through the browser.

Type	How you add it	Typical use
Local (stdio)	A command plus arguments, like npx -y some-package	Browser control, local files, your own database
Remote (HTTP)	A URL, sometimes with a token or browser login	Hosted services like issue trackers and docs

Older setups sometimes use an SSE transport instead of HTTP. If a server's docs offer both, pick HTTP.

Add a server in Cursor

Per Cursor's docs, you can manage servers from settings or configure them in an mcp.json file. Use .cursor/mcp.json in your project for project-specific tools. Use ~/.cursor/mcp.json for tools you want everywhere.

1. Create .cursor/mcp.json in your project root.
2. Add an entry under mcpServers.
3. Restart Cursor, then open an agent chat and check that the server's tools show up.

A local server entry looks like this. I'm using the Playwright browser server as the example:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"]
    }
  }
}

A remote server swaps command and args for a url, plus headers if it needs a token. Cursor can fill in variables in these fields, so you can reference an environment variable instead of pasting a secret into the file.

If nothing shows up, the usual suspects are invalid JSON, the file in the wrong place, or an environment variable Cursor can't see.

Add a server in Claude Code

Claude Code skips the JSON editing. Its MCP quickstart shows the commands. For a local server:

claude mcp add playwright -- npx -y @playwright/mcp@latest

For a remote one, the general form is claude mcp add --transport http <name> <url>. The name is whatever you want to call it. Claude Code uses it to label the server's tools and in commands like claude mcp remove.

Then start a session and run /mcp to see the server's status and sign in if it needs OAuth. claude mcp list shows everything you've registered.

Scope matters. The same docs say user-scoped servers (--scope user) are written to ~/.claude.json, while project-scoped servers live in .mcp.json at the project root. Project scope is the one to use if you want teammates to get the same setup.

Editor	Project config	Global/user config
Cursor	.cursor/mcp.json	~/.cursor/mcp.json
Claude Code	.mcp.json	~/.claude.json

What about Windsurf, Lovable, Bolt, v0, and Replit? Support and setup differ by tool, and I didn't verify each one. Check your editor's own docs for an MCP or "connectors" section before assuming the steps above apply.

A prompt to test your new server

Once a server is connected, don't jump straight into a big task. Run a small, read-only check first. Paste this into your agent chat:

List every MCP tool you can see right now, grouped by server.
For each one, say in one line what it does and whether it
can change data (write/delete) or only read.
Then use one read-only tool to do something harmless
and show me exactly what you called and what came back.
Don't call any write or delete tool without asking me first.

This confirms the connection works. It also shows you what you just handed the AI, which is the part people skip.

The part nobody likes: security

An MCP server is code running with your credentials, and its output goes straight into your model's context. Treat it like installing a dependency, because that's what it is.

The main risks are prompt injection and tool poisoning. Prompt injection hides instructions in content the AI reads, like a ticket, a web page, or a file. Tool poisoning is the same trick aimed at the server itself: a malicious server puts instructions in its tool descriptions. OWASP's write-up recommends keeping an allowlist of approved servers. It also says to ask the user for approval before destructive or data-leaking actions, and to enforce access limits in the tool layer rather than only in the prompt.

In practice, that comes down to a few habits:

• Install only servers you can vouch for. Prefer official ones from the service's own team, and read the repo before you run it.
• Use least privilege. Give the server a read-only token, or point a database server at a dev copy, not production.
• Keep approvals on. Don't auto-approve tools that write, delete, send, or spend.
• Don't paste secrets into config files you commit. Use environment variables.
• Watch the risky combination. Private data, untrusted content, and a way to send data out, all in one session, is how injection turns into a leak.
• Remove what you don't use. Fewer servers means a smaller attack surface and less clutter for the model to sort through.

When MCP is the wrong tool

Sometimes a plain shell command is simpler. If your AI can already run gh or psql in the terminal, an MCP server may add little beyond more setup. MCP earns its place when there's no good CLI, when you want structured results, or when you want sign-in handled for you.

FAQ

Is MCP the same as an API?

No. An API is how one service exposes itself to code. An MCP server usually wraps an API and describes its capabilities in a standard way, so any MCP-aware editor can discover and use them without custom integration code.

Do I need to write my own MCP server?

Usually not. Most popular services already have a server, and the setup is one command or a few lines of JSON. Write your own only if you have an internal tool or API that nothing off the shelf covers.

Can one MCP server work in multiple editors?

Yes, that's the point of the standard. A server's setup instructions may be written for a different client than yours, so you may need to translate them. The server itself stays the same. Only the config format or add command changes.

Cover photo: Samsung Memory on Unsplash