MCP Servers for Web Development: Choose Access First

MCP servers let an AI coding tool such as Cursor, Claude Code or VS Code reach things outside your editor: an issue tracker, a browser, a database, your error monitoring. That is useful, but every server you add is also a new set of permissions handed to an AI agent. The right question is not "which MCP servers are best?" but "what access does this task actually need, and what is the smallest way to give it?"

This guide is for web developers, freelancers and technical founders deciding whether to connect their AI coding tools to other systems. It covers what MCP is, a task-to-access table, a decision tree, read-only setup and secrets, configuration in Cursor, Claude Code and VS Code, a demo workflow on a throwaway project, untrusted output risks and when not to add a server.

Everything about the protocol and each tool below was checked against the official documentation on November 10, 2026. These tools change quickly, so confirm details in the linked docs before you rely on them.

What is MCP?

The Model Context Protocol (MCP) is an open protocol that standardizes how AI applications connect to external data sources and tools. The official specification describes three roles:

• Host: the AI application you use, such as Cursor, Claude Code or VS Code.
• Client: a connector inside the host. The host creates one client for each server it connects to.
• Server: a program that provides context and capabilities to the client.

Messages between client and server use JSON-RPC 2.0. If JSON APIs are new to you, start with what an API is. The spec says MCP takes inspiration from the Language Server Protocol, which standardized how editors support programming languages.

The current protocol version listed on modelcontextprotocol.io is 2026-07-28. Versions are dated by the last backwards-incompatible change, so a server or client may support an earlier version and still work.

What an MCP server adds

An MCP server can offer three kinds of features, according to the spec:

• Tools: functions the AI model can call, such as "create an issue", "run a query" or "open this page in a browser".
• Resources: data the model or user can read, such as a database schema or a file.
• Prompts: reusable templates the user can trigger.

Clients can offer elicitation, which lets a server ask you for more information or a confirmation during a task.

Servers run in one of two ways:

• Local servers usually use the stdio transport. Your AI tool starts the server as a process on your machine and talks to it through standard input and output.
• Remote servers use the Streamable HTTP transport. The server runs on the provider's infrastructure and your tool connects over HTTPS, usually signing in with OAuth.

The MCP project's own local server security guide says a local server is an ordinary operating system process that inherits your user account's access: it can read files your account can read, see environment variables passed to it and open network connections. The stdio transport is not a sandbox.

So an MCP server adds two things at once: a capability (the agent can now do X) and a level of access (the agent can now touch Y). Decide on the access first.

Match tasks to access requirements

Before you install anything, write down the task and the minimum access it needs. Most web development tasks need much less than a server's full tool list.

Reading is far more common than writing, and most tasks touch one project, not a whole account. If a server wants account-wide write access for a read-only, single-repo job, configure it more narrowly or pick another approach.

Connector, direct integration or no added tool

You usually have three options for giving an AI tool access to a system:

1. A connector or remote MCP server from the provider. Many services publish an official remote endpoint, often listed in a host's marketplace. VS Code also offers Copilot connectors (in preview), GitHub-managed MCP connections with no local setup.
2. A direct integration you control. A short script, a CLI or the service's own API with a scoped key. You see exactly what it does.
3. Nothing. Use the agent's built-in tools (files, terminal, browser) or paste the information yourself.

Use this decision tree:

1. Can the agent already do this with its built-in tools? VS Code's documentation, for example, suggests trying its built-in browser tools before adding a browser automation server. If yes, add nothing.
2. Is this a one-off? Copy the data in yourself. A server installed for one question stays in the model's context.
3. Does the provider offer an official remote server or connector? If yes, prefer it. The MCP security guide recommends the remote version where one exists, because it runs no code on your machine, uses the protocol's authorization flow instead of a token in a config file, and is patched in one place.
4. Does the task need local access (your working tree, a local database, a local browser)? Then a local server can make sense. Pick one whose source and publisher you can identify, pin the version and run it with the narrowest settings.
5. Is the action destructive, account-wide or hard to undo? Do it yourself, or write a small script you review and run by hand. Don't wire it to an agent.
6. None of the above, but you call the same API repeatedly? A direct integration with a scoped key may be simpler and easier to audit than a third-party server.

Read-only first: permissions and secrets

Start every new server in its most restricted mode and widen access only when a real task needs it.

Choose read-only modes and narrow toolsets where offered. GitHub's official MCP server, for example, documents a read-only mode (the X-MCP-Readonly header or a /readonly URL for the remote server, and a --read-only flag for the local one) that disables write tools even if they are explicitly requested, plus toolset options to load only the groups you need, such as issues and pull requests.

Scope tokens narrowly. The MCP local security guide recommends giving each server its own token with the smallest scope that works, such as a fine-grained token limited to one repository rather than an account-wide token. Claude Code's documentation gives the same pattern for GitHub and suggests a read-only database user when connecting a database server.

Prefer OAuth for remote servers. Cursor, Claude Code and VS Code all support OAuth sign-in for remote MCP servers. Claude Code also lets you pin the OAuth scopes it requests with an oauth.scopes setting, which helps when a provider advertises more scopes than you want to grant.

Keep secrets out of committed files. Project-level MCP config files are often committed so a team shares the same setup. That makes them the wrong place for tokens:

• In Cursor, reference environment variables with ${env:NAME} in mcp.json, or load an envFile for stdio servers.
• In Claude Code, .mcp.json supports ${VAR} and ${VAR:-default} expansion, so the committed file can name a variable without containing its value.
• In VS Code, the docs say not to commit tokens, passwords or populated authentication headers, and note that a personal configuration file is not a secret store. The VS Code .vscode/mcp.json format supports input variables that prompt for a secret and store it securely.

Limit files and network. For servers that work with files, grant one project directory, read-only if possible, never your home directory. The MCP guide notes that config-level allowlists are cooperative: an honest server respects them, but real enforcement comes from isolation such as a container. VS Code can sandbox local stdio servers on macOS and Linux (sandboxEnabled with file system and network rules), and the MCP guide suggests running third-party servers in a container with nothing mounted except the directory they need.

Keep tool approvals on. Cursor asks for approval before running MCP tools by default, Claude Code asks you to approve project-scoped servers from .mcp.json in interactive sessions, and VS Code shows server trust prompts to review before you accept them. Auto-approving everything removes the moment you would notice an unexpected tool call.

How to configure MCP servers in Cursor, Claude Code and VS Code

Each tool uses a different file and a slightly different format, so check the format before copying a config between tools.

Cursor

Cursor reads .cursor/mcp.json in your project for project-specific servers and ~/.cursor/mcp.json for servers available everywhere. A local server needs a command, optional args and optional env; a remote server needs a url and optional headers:

{
  "mcpServers": {
    "docs": {
      "url": "https://mcp.example.com/mcp"
    },
    "local-tool": {
      "command": "npx",
      "args": ["-y", "example-mcp-server@1.2.3"],
      "env": { "API_KEY": "${env:EXAMPLE_API_KEY}" }
    }
  }
}

Names and packages above are placeholders; use the publisher's exact package name and a pinned version. Cursor supports stdio, SSE and Streamable HTTP, lets you toggle a server off from Customize without deleting it, and shows logs in the Output panel under "MCP Logs". For plan limits, see our Cursor pricing guide.

Claude Code

Claude Code adds servers from the command line. A remote HTTP server:

claude mcp add --transport http docs https://mcp.example.com/mcp

A local stdio server, with everything after -- passed to the server's own command:

claude mcp add --transport stdio local-tool --env API_KEY=your-key -- npx -y example-mcp-server@1.2.3

Servers have three scopes. Local (the default) is private to you in the current project and stored in ~/.claude.json. Project is shared through a .mcp.json file at the project root that you can commit. User is available in all your projects, also stored in ~/.claude.json. Use claude mcp list, claude mcp get <name> and claude mcp remove <name> to manage them, and /mcp inside a session to check status or sign in with OAuth.

One detail worth knowing: in JSON config, an entry with a url but no type is treated as a stdio server and skipped with an error, so add "type": "http" when you copy a remote config from another tool. Claude Code permission rules can also reference individual MCP tools by name, which lets you deny a tool you don't want used. For how Claude Code compares with other agents, see Cursor vs Claude Code vs Codex.

VS Code

VS Code now supports two formats:

• The VS Code format in .vscode/mcp.json (or your user profile), with a top-level servers object. It supports input variables for secrets, envFile, a working directory and per-server sandboxing.
• The portable format in a workspace-root .mcp.json or ~/.copilot/mcp-config.json, with a top-level mcpServers object, which Copilot harness sessions read directly.

The guided flow (run MCP: Add Server from the Command Palette, or Chat: Open Customizations and select MCP Servers) asks whether you have a server URL (HTTP) or a launch command (stdio) and where to store it. A minimal VS Code-format entry looks like this:

{
  "servers": {
    "local-tool": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "example-mcp-server@1.2.3"]
    }
  }
}

VS Code's documentation makes a useful point: adding a configuration isn't proof that the agent can use the server. After adding one, run a low-impact prompt that names the server, expand the tool call in the chat, and check that the tool came from the server you added and that the answer reflects its output.

Demo: test a server on a disposable project

The steps below are a demo workflow, not a report of results. It shows how to try a new MCP server without exposing real code, data or credentials. Adapt the commands to the server you are evaluating.

1. Create a throwaway project. Make a new folder outside your real work, initialise a fresh starter app or an empty Git repo, and don't copy in any .env files. If the server needs an account, use a test account or a sandbox workspace.
2. Check provenance. Find the server's source repository and publisher, confirm the exact package name in the official docs (typosquatted names are a known risk), and choose a specific version rather than latest.
3. Read the tool list without a model in the loop. The MCP Inspector runs with npx @modelcontextprotocol/inspector (it needs Node 22.19.0 or newer) and lists every tool a server exposes. Read the tool descriptions. If one contains instructions unrelated to its job, don't use the server.
4. Add it at project scope only. Use .cursor/mcp.json, a project-scoped .mcp.json in Claude Code, or a workspace config in VS Code, so the server exists only in the throwaway project.
5. Run one low-impact prompt. For example: "Use the [server name] tools to list what you can read in this project. Do not change any files." Approve each tool call only after reading its arguments.
6. Inspect the transcript. Confirm which server handled each call, what it returned and whether it tried anything you didn't ask for.
7. Decide, then clean up. If the server is worth keeping, add it to a real project with the narrowest scope and token. Either way, remove it from the test project, revoke any test token, and delete the folder.

Untrusted output and failure modes

MCP servers bring outside text into the model's context, and the model can't reliably tell data from instructions. The main risks:

• Prompt injection through content. An issue, web page, email or database row can contain text written to steer the agent. Claude Code's docs warn that servers that fetch external content can expose you to prompt injection risk. Treat anything a server returns as untrusted input, the same way you would treat user input in a web form.
• Tool poisoning and changing definitions. The MCP local security guide notes that tool names and descriptions are themselves instructions the model reads, that a server can hide directives in them aimed at other servers' tools, and that definitions can change after you approve a server. Some clients ask again when a tool definition changes; that is worth choosing a client for.
• Shared context across servers. Every server you configure shares the same model context, so a malicious or compromised server can influence how the agent uses all the others. Each new server extends the risk to the rest.
• Supply chain. A legitimate server can pull in a compromised dependency. The guide points out that pinning a package version with npx or uvx fixes only the top-level package, while pinning a container image by digest freezes the whole dependency tree.
• Ordinary failures. Servers crash, time out or lose authentication. An agent that can't reach a tool may guess instead, so check that answers come from real tool output.

The spec's own security principles are a good checklist: users should explicitly consent to data access and actions, tools represent arbitrary code execution, and tool descriptions should be considered untrusted unless they come from a trusted server.

When not to add an MCP server

Skip the server when:

• The agent's built-in tools already cover it. Reading files, running your test suite or opening a local page often needs nothing extra.
• You need the information once. Paste it in.
• The only option needs broader access than the task. An account-wide token for a single-repo job is a bad trade.
• It touches production data, payments, DNS or user accounts. Use read-only copies or staging, or do the task yourself.
• You can't identify the publisher or read the source. The MCP guide's default: only install servers whose source code you can read and whose publisher you can identify.
• It ships only as a local process but just wraps a remote API. The guide treats that as a signal worth questioning; prefer an official remote version.
• You already have many servers enabled. More servers mean more tools in the model's context and more surface for the problems above. VS Code's docs put it plainly: if your existing tools meet your needs, you don't need another server.

A useful habit from the MCP security guide: open your MCP config now and then, remove servers you no longer use, and make sure you know where each remaining one comes from and that its version is pinned.

FAQ

Next steps

Pick one task you currently do by copying data into chat, check which access it really needs using the table above, and try a server on a throwaway project before connecting it to anything real. For the wider tool landscape, read our guide to AI tools for web development; for the basics behind tokens and endpoints, see what an API is; and for plan costs, see Cursor pricing and Claude Code pricing. If you want help setting up an AI-assisted workflow for your site, get in touch.

Official sources

Checked November 10, 2026: MCP specification · MCP architecture overview · MCP local server security · MCP security best practices · MCP Inspector · Cursor MCP docs · Claude Code MCP docs · VS Code: add MCP servers · VS Code MCP configuration reference · GitHub MCP server configuration.