The top 15 MCP servers for your AI projects

The Model Context Protocol (MCP) has settled into its role as the standard way to connect AI models to external tools and data. It is now backed by the Agentic AI Foundation under the Linux Foundation, with Anthropic, OpenAI, Google, and Microsoft on the board, and it powers everything from file system access and API integrations to database queries and automated workflows across clients like Claude Desktop, Claude Code, Cursor, and VS Code.

This guide walks through 15 essential MCP servers for web developers, with current setup steps, use cases, and the config you actually need. For a full walkthrough on getting started with MCP servers, check out this article.

What is the difference between stdio and Streamable HTTP?

MCP servers speak JSON-RPC over a transport. Early remote servers used an HTTP+SSE transport that required two endpoints: a long-lived GET /sse stream for server-to-client messages and a separate POST endpoint for requests. That design was fragile behind load balancers and serverless platforms, and it was deprecated in the 2025 spec revision in favor of Streamable HTTP, which uses a single endpoint (typically /mcp) that can optionally upgrade to an SSE stream for long-running calls. With the current stable spec, only two transports are recognized: stdio for local servers, the client launches as a subprocess, and Streamable HTTP for anything remote or multi-client.

Two more things worth knowing. Remote servers have largely standardized on OAuth 2.1, replacing hand-rolled token flows, and now support a browser-based sign-in. There is ongoing work to make the protocol fully stateless, but it is not final yet. For more details, refer to the official MCP documentation.

Below is a comparison table of the 15 servers this guide covers, showing their transports, authentication, and hosting at a glance.

Which MCP servers should you install first?

If you’re just getting started with MCP, begin with GitHub, MCP, Context7, and Playwright. They provide repository context, up-to-date documentation, and browser automation, covering the majority of developer workflows. From there, add cloud, database, or monitoring servers as your projects require them.

Below are the 15 MCP servers every web developer should know.

What can the GitHub MCP server do?

The GitHub MCP server lets AI models analyze code, manage repositories, and drive development workflows through natural language. GitHub runs a hosted remote server that lives at https://api.githubcopilot.com/mcp/ and authenticates with OAuth 2.1 plus PKCE, which means short-lived credentials and automatic token refresh instead of a long-lived personal access token. Here is the remote configuration:

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    }
  }
}

Most clients will trigger a browser-based OAuth login on first use. If you prefer a token, you can still pass a PAT as a bearer header, and it takes precedence over OAuth:

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer ${input:github_mcp_pat}"
      }
    }
  }
}

The local server runs in Docker and is the right choice for GitHub Enterprise Server, which does not host the remote endpoint.

{
  "mcp": {
    "inputs": [
      {
        "type": "promptString",
        "id": "github_token",
        "description": "GitHub Personal Access Token",
        "password": true
      }
    ],
    "servers": {
      "github": {
        "command": "docker",
        "args": [
          "run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
          "ghcr.io/github/github-mcp-server"
        ],
        "env": {
          "GITHUB_PERSONAL_ACCESS_TOKEN": "${input:github_token}"
        }
      }
    }
  }
}

You can scope what the server exposes with the --toolsets flag, and the server offers a read-only mode via the --read-only flag (or GITHUB_READ_ONLY=1 in Docker), which is useful for code review workflows where you want context without write access.

Sample use cases

Teams use it for pull request management, issue tracking driven by repository activity, and code scanning triage, where the model reviews alerts and suggests remediation. The GA remote server also added security advisory lookups, sub-issue management, and PR draft toggling.

const prWorkflow = async (client) => {
 const pr = await client.callTool({
   name: 'create_pull_request',
   arguments: {
     owner: 'owner',
     repo: 'repo',
     title: 'Automated feature update',
     head: 'branch',
     base: 'main'
   }
 });
const alerts = await client.callTool({
name: 'list_code_scanning_alerts',
arguments: { owner: 'owner', repo: 'repo' }
});
return { pullRequest: pr, securityAlerts: alerts };
};

What can the MongoDB MCP server do?

The MongoDB MCP server enables natural language queries and data exploration against MongoDB databases and Atlas clusters. It supports direct database operations like find, aggregate, insert, update, and delete, alongside Atlas management tools for cluster administration, user management, and project configuration.

One thing to note: MongoDB recommends Node 22.13 or later, or the Docker image, which sidesteps Node entirely. If you use Claude Code, Codex, Cursor, or Gemini, MongoDB ships an official plugin bundle that includes the server plus prebuilt agent skills.

The default transport is stdio. Here is a connection-string setup:

{
  "mcpServers": {
    "MongoDB": {
      "command": "npx",
      "args": ["-y", "mongodb-mcp-server@latest", "--readOnly"],
      "env": {
        "MDB_MCP_CONNECTION_STRING": "mongodb+srv://username:password@cluster.mongodb.net/myDatabase"
      }
    }
  }
}

Passing credentials through environment variables rather than command-line arguments is the recommended practice, since arguments can show up in process lists and logs. MongoDB ships every example with --readOnly on by default; remove it only when you actually need writes.

For Atlas management tools, authenticate with a service account:

{
  "mcpServers": {
    "MongoDB": {
      "command": "npx",
      "args": ["-y", "mongodb-mcp-server@latest", "--readOnly"],
      "env": {
        "MDB_MCP_API_CLIENT_ID": "your-atlas-service-account-client-id",
        "MDB_MCP_API_CLIENT_SECRET": "your-atlas-service-account-client-secret"
      }
    }
  }
}

It also includes Performance Advisor tools that surface suggested indexes, unified index creation that handles both regular and vector search indexes, and local cluster management so the server can spin up a MongoDB instance without a separate install.

Sample applications

E-commerce platforms run aggregation pipelines over customer behavior data to generate recommendations.

const productAnalysis = await client.callTool({
 name: 'aggregate',
 arguments: {
   collection: 'products',
   pipeline: [
     { $match: { stock: { $lt: 10 } } },
     { $lookup: { from: 'orders', localField: '_id', foreignField: 'productId', as: 'orders' } },
     { $addFields: { orderCount: { $size: '$orders' } } },
     { $sort: { orderCount: -1 } }
   ]
 }
});

How does the Azure MCP server work?

The Azure MCP server gives AI models natural language control over Microsoft Azure services, including Azure Storage, Cosmos DB, Log Analytics, App Configuration, and direct Azure CLI and Azure Developer CLI command execution. The Azure MCP Server consolidates more than 40 Azure services into a single server.

Installation uses npx, and the server defaults to stdio. Most clients use an mcpServers root object, but Visual Studio and VS Code use servers:

{
  "mcpServers": {
    "Azure MCP Server": {
      "command": "npx",
      "args": ["-y", "@azure/mcp@latest", "server", "start"]
    }
  }
}

For remote hosting (for example, with Microsoft Foundry or Copilot Studio), the server can be self-hosted on Azure Container Apps and exposed over Streamable HTTP with Microsoft Entra authentication.

Use cases

DevOps teams use it for infrastructure management and deployment through the Azure CLI, and operations teams for monitoring queries against Log Analytics.

const resourceAnalysis = async (client) => {
 const storageAccounts = await client.callTool({
   name: 'list_storage_accounts',
   arguments: {}
 });
const logQuery = await client.callTool({
name: 'query_log_analytics',
arguments: {
workspace: 'my-workspace',
query: 'AppMetrics | where TimeGenerated > ago(1h) | summarize avg(Value) by bin(TimeGenerated, 5m)'
}
});
return { storage: storageAccounts, metrics: logQuery };
};

Why should you use Context7 MCP?

Context7 MCP server solves a narrow but constant problem: coding agents hallucinate library APIs because their training data lags behind current releases. Context7 fetches version-specific documentation for a library on demand and injects it into the model’s context, so the agent writes code against current Next.js or Prisma signatures rather than outdated ones.

It is a community server maintained by Upstash, and it runs either locally over stdio or as a hosted remote endpoint. The local setup is a single line:

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

The hosted remote endpoint uses Streamable HTTP. An API key is optional (the free tier works without one) but raises your rate limits, and it is passed as a header:

{
  "mcpServers": {
    "context7": {
      "type": "http",
      "url": "https://mcp.context7.com/mcp",
      "headers": {
        "CONTEXT7_API_KEY": "YOUR_API_KEY"
      }
    }
  }
}

In use, you invoke it by naming it in a prompt, and the server exposes only two tools, resolve-library-id and query-docs, which keep its context footprint small compared to servers that inject dozens of tool definitions.

Sample applications

The clearest win is on fast-moving frameworks. Asking an agent to configure middleware in the current Next.js without Context7 often yields an answer built on an older API. The limitation is index coverage as very new or private libraries may not be indexed yet, in which case a direct documentation fetch is the fallback.

const libraryId = await client.callTool({
 name: 'resolve-library-id',
 arguments: { query: 'app router middleware', libraryName: 'next.js' }
});
const docs = await client.callTool({
name: 'query-docs',
arguments: {
libraryId: libraryId,
query: 'how do I set up app router middleware'
}
});

What can the Cloudflare MCP server do?

The Cloudflare MCP server gives natural language control over Cloudflare’s network, spanning Workers, observability, Radar, DNS analytics, and more. Two aspects of its design are worth understanding before you set it up.

First, Cloudflare’s remote servers use Streamable HTTP at a /mcp endpoint, and second, Cloudflare runs a Code Mode server at https://mcp.cloudflare.com that exposes the entire Cloudflare API, over 2,500 endpoints, through just two tools, search() and execute(). Rather than loading thousands of tool definitions into context, the model writes JavaScript against a typed representation of the API, which keeps token usage roughly flat regardless of how much of the API you touch.

For the broad Code Mode server, connect via OAuth:

{
  "mcpServers": {
    "cloudflare": {
      "type": "http",
      "url": "https://mcp.cloudflare.com/mcp"
    }
  }
}

The product-specific servers are still available for curated, typed tools in a single domain. For clients without native remote support, wrap them with mcp-remote, now pointing at /mcp:

{
  "mcpServers": {
    "cloudflare-observability": {
      "command": "npx",
      "args": ["mcp-remote", "https://observability.mcp.cloudflare.com/mcp"]
    },
    "cloudflare-bindings": {
      "command": "npx",
      "args": ["mcp-remote", "https://bindings.mcp.cloudflare.com/mcp"]
    }
  }
}

When you connect, Cloudflare redirects you through an OAuth flow to authorize and scope permissions. For CI or automation, you can pass a scoped Cloudflare API token as a bearer token instead.

Sample applications

Performance teams tune caching from Radar insights, security teams triage threats from observability data, and platform teams manage bindings and Workers. With the Code Mode server, “create a KV namespace called session-cache and bind it to my auth-worker” becomes a search() for the relevant endpoints followed by an execute().

How do you use the Firebase MCP server?

The Firebase MCP server integrates with Google’s Firebase platform, letting AI models manage Firestore, Authentication, Cloud Functions, and hosting through natural language, along with project initialization and SDK configuration.

It ships as a command inside the Firebase CLI and runs over stdio.

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

You can scope it to a project directory and filter which feature groups are active, which is a good habit for keeping the tool surface tight:

{
  "mcpServers": {
    "firebase": {
      "command": "npx",
      "args": [
        "-y", "firebase-tools@latest", "mcp",
        "--dir", "/path/to/project",
        "--only", "auth,firestore,storage"
      ]
    }
  }
}

Authentication comes from the Firebase CLI, so run firebase login first if you are not already signed in.

Sample use cases

Teams use it to inspect Firestore data, drive Cloud Messaging campaigns from engagement data, and manage users through Firebase Auth.

const firebaseWorkflow = async (client) => {
 const project = await client.callTool({
   name: 'firebase_get_project',
   arguments: {}
 });
const userData = await client.callTool({
name: 'firestore_query_collection',
arguments: {
collection: 'users',
filter: 'lastActive > 2026-01-01'
}
});
return { project, userData };
};

How do you deploy applications with the Google Cloud Run MCP server?

The Google Cloud Run MCP server automates deployment and management of containerized applications on Cloud Run, covering direct file and folder deployment, service management, and Google Cloud project operations.

For local development, it runs over stdio and authenticates through the Google Cloud SDK. The server is published on npm as @google-cloud/cloud-run-mcp:

# Prerequisites: Node.js, Google Cloud SDK
gcloud auth login
gcloud auth application-default login
{
"mcpServers": {
"cloud-run": {
"command": "npx",
"args": ["-y", "@google-cloud/cloud-run-mcp"]
}
}
}

You can also deploy the MCP server itself onto Cloud Run for remote scenarios. Cloud Run hosts MCP servers over Streamable HTTP (it does not host stdio servers), and the server supports OAuth. A minimal OAuth-mode client config points at the /mcp endpoint:

gcloud run deploy cloud-run-mcp \
  --image us-docker.pkg.dev/cloudrun/container/mcp \
  --no-allow-unauthenticated
gcloud run services proxy cloud-run-mcp --port=3000 --region=REGION
{
"mcpServers": {
"cloud-run": {
"httpUrl": "http://localhost:3000/mcp",
"oauth": { "enabled": true }
}
}
}

Application scenarios

Teams deploy services with model-chosen configurations directly from their IDE or AI assistant applications, and manage project configuration across environments.

const deploymentWorkflow = async (client, projectId, region) => {
 const deployment = await client.callTool({
   name: 'deploy-local-folder',
   arguments: {
     folder_path: './my-app',
     service_name: 'my-new-service',
     project: projectId,
     region: region
   }
 });
return { newDeployment: deployment };
};

How does the JetBrains MCP server work?

The JetBrains MCP server connects AI models to JetBrains IDEs, including IntelliJ IDEA, PyCharm, WebStorm, and Android Studio, enabling code intelligence, refactoring suggestions, and project analysis from inside the IDE. It works through a proxy that bridges MCP clients to the IDE’s built-in server, and it runs over stdio.

Install the JetBrains MCP plugin from the Marketplace (plugin ID 26071-mcp-server), then configure the proxy:

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

To target a specific IDE instance, set the port:

{
  "mcpServers": {
    "jetbrains": {
      "command": "npx",
      "args": ["-y", "@jetbrains/mcp-proxy"],
      "env": {
        "IDE_PORT": "63342",
        "HOST": "127.0.0.1",
        "LOG_ENABLED": "true"
      }
    }
  }
}

Because the connection is local to the running IDE, there is no separate authentication step.

Development use cases

Teams pull IDE inspection results for review feedback, get refactoring suggestions grounded in the IDE’s own analysis, and generate docs from code context.

const ideWorkflow = async (client) => {
 const projectInfo = await client.callTool({
   name: 'get_project_structure',
   arguments: {}
 });
const codeAnalysis = await client.callTool({
name: 'run_code_inspections',
arguments: { scope: 'project', include_warnings: true }
});
return { project: projectInfo, analysis: codeAnalysis };
};

How does the Docker MCP Toolkit work?

Docker provides an official MCP Catalog and Toolkit that is the recommended way to run and manage MCP servers, including containerized database, monitoring, and API servers.

The Catalog is a curated registry of containerized MCP servers on Docker Hub, each running in an isolated container. The Toolkit, built into Docker Desktop, lets you browse the catalog, add credentials, and connect a server to clients like Claude Desktop, Cursor, and VS Code with a click, no manual config files. Every catalog entry is labeled by trust level, either Docker-built with signed and verified images or community-built and containerized by the publisher.

Setup happens through Docker Desktop rather than a hand-written config. Enable the MCP Toolkit, pick servers from the catalog, and connect your client. The value here is security and isolation. Instead of running an assortment of npx and uvx processes with direct access to your machine, each server runs in a sandboxed container, and the Gateway gives you one place to audit and govern them.

Operational use cases

Teams configure containerized environments through natural language, inspect container performance, and spin up isolated environments. Because the Toolkit standardizes how servers are packaged and connected, the benefit is less about any single tool call and more about running a fleet of servers safely from one control point.

How do you use the Figma MCP server for design-to-code workflows?

The Figma MCP server gives AI models access to Figma design files for design analysis and code generation. Figma runs an official remote server, which is the recommended setup, alongside a local desktop server for specific enterprise cases.

The remote server connects over Streamable HTTP at https://mcp.figma.com/mcp, works without the desktop app, and is available on all seats and plans:

{
  "mcpServers": {
    "figma": {
      "type": "http",
      "url": "https://mcp.figma.com/mcp"
    }
  }
}

Authentication is handled through your client’s OAuth flow. A desktop server also exists for specific organization and enterprise cases, running locally at http://127.0.0.1:3845/mcp, but Figma recommends the remote server for the broadest feature set.

Once connected, you provide context by copying a link to a frame or layer and referencing it in a prompt. The server extracts the node ID from the URL and pulls the relevant design data. Beyond reading designs, it can write back to the canvas, generate Figma content from live UI, and create FigJam diagrams.

Design workflow applications

Frontend teams generate framework components from designs using tools like get_code and get_variable_defs, and design systems teams extract variables to compare implementations against established design tokens.

const designToCode = async (figmaClient) => {
 const codeStructure = await figmaClient.callTool({
   name: 'get_code',
   arguments: { selection: 'current_figma_selection' }
 });
const designTokens = await figmaClient.callTool({
name: 'get_variable_defs',
arguments: { frame_id: 'frame_id_from_url' }
});
return { reactCode: codeStructure, designTokens };
};

How do you use the AWS MCP server?

AWS offers two paths. The fully managed remote server at https://aws-mcp.us-east-1.api.aws/mcp covers AWS documentation and 15,000+ AWS APIs, and is the recommended default for broad access. Because MCP clients speak OAuth while the AWS endpoint expects SigV4-signed requests, you connect through a small stdio proxy, mcp-proxy-for-aws, that signs requests using your local AWS credentials.

For a deliberately small blast radius, AWS Labs publishes a catalog of specialized open-source servers, each scoped to one service or workflow: AWS Documentation, Bedrock Knowledge Bases, CDK for infrastructure as code, Cost Analysis, Lambda execution, and more. The full inventory lives at the AWS Labs MCP catalog.

The managed server connects through the proxy, launched via uvx:

{
  "mcpServers": {
    "aws-mcp": {
      "command": "uvx",
      "transport": "stdio",
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://aws-mcp.us-east-1.api.aws/mcp"
      ]
    }
  }
}

The specialized AWS Labs servers install through UVX and run over STDIO, with most also offering a Streamable HTTP variant suitable for hosting on Lambda or fronting with the Bedrock AgentCore Gateway:

# Prerequisites: install uv, configure AWS credentials
uv python install 3.10
{
"mcpServers": {
"awslabs.core-mcp-server": {
"command": "uvx",
"args": ["awslabs.core-mcp-server@latest"],
"env": { "FASTMCP_LOG_LEVEL": "ERROR" }
},
"awslabs.aws-documentation-mcp-server": {
"command": "uvx",
"args": ["awslabs.aws-documentation-mcp-server@latest"],
"env": { "FASTMCP_LOG_LEVEL": "ERROR" }
},
"awslabs.cost-analysis-mcp-server": {
"command": "uvx",
"args": ["awslabs.cost-analysis-mcp-server@latest"],
"env": {
"AWS_PROFILE": "your-aws-profile",
"FASTMCP_LOG_LEVEL": "ERROR"
}
}
}
}

For remote deployments, the AgentCore Gateway is worth knowing about. It fans multiple MCP servers, REST APIs, or Lambda functions out to agents over a single Streamable HTTP endpoint with OAuth 2.1 on the front and IAM-scoped access on the back, and it adds a semantic tool search so agents can find the right tool without loading every definition.

Cloud management applications

Teams analyze spend through the Cost Analysis server and generate CDK or Terraform configurations that follow AWS best practices.

const awsWorkflow = async (docClient, costClient) => {
 const docResults = await docClient.callTool({
   name: 'search_documentation',
   arguments: { query: 'Lambda best practices security', max_results: 10 }
 });
const costAnalysis = await costClient.callTool({
name: 'analyze_costs',
arguments: { time_period: 'last_30_days', service: 'lambda', include_recommendations: true }
});
return { documentation: docResults, costs: costAnalysis };
};

How do you deploy projects with the Netlify MCP server?

The Netlify MCP server handles project creation and deployment from your editor, wraps Netlify CLI functionality, and manages the full project lifecycle through the Netlify API and CLI. It runs over stdio.

# Prerequisites: current Node.js LTS, Netlify account, Netlify CLI
npm install -g netlify-cli
{
"mcpServers": {
"netlify-mcp": {
"command": "npx",
"args": ["-y", "@netlify/mcp"]
}
}
}

If you hit authentication issues, you can pass a personal access token through the environment:

{
  "mcpServers": {
    "netlify-mcp": {
      "command": "npx",
      "args": ["-y", "@netlify/mcp"],
      "env": {
        "NETLIFY_PERSONAL_ACCESS_TOKEN": "your_pat_value"
      }
    }
  }
}

Run netlify login first if you are not already authenticated through the CLI. Node 22 or later is recommended.

Deployment use cases

Teams deploy directly from the editor, manage build configuration, and automate extension management.

const netlifyWorkflow = async (client, projectPath) => {
 const project = await client.callTool({
   name: 'create_project',
   arguments: {
     name: 'my-jamstack-site',
     build_command: 'npm run build',
     publish_directory: 'dist'
   }
 });
const deployment = await client.callTool({
name: 'deploy_site',
arguments: { project_path: projectPath, production: true }
});
return { project, deployment };
};

What can the Prisma MCP server do?

The Prisma MCP server covers Prisma Postgres database management, schema migrations, database provisioning by region, and Prisma Console authentication. It runs over stdio through the Prisma CLI.

{
  "mcpServers": {
    "Prisma": {
      "command": "npx",
      "args": ["-y", "prisma", "mcp"]
    }
  }
}

For Claude Code, add it from the terminal:

claude mcp add prisma npx prisma mcp

The same config works across clients that read a standard MCP JSON file, including Cursor at ~/.cursor/mcp.json.

Database development applications

Teams create tables and manage migrations while preserving data integrity, provision Prisma Postgres instances by region, and handle Console authentication for visual management.

const prismaWorkflow = async (client) => {
 const database = await client.callTool({
   name: 'create_database',
   arguments: { region: 'us-east-1', name: 'production-db' }
 });
const table = await client.callTool({
name: 'create_table',
arguments: { database_id: database.id, table_name: 'Product' }
});
return { database, table };
};

How does the Sentry MCP server help with debugging?

The Sentry MCP server fills the gap in connecting your AI directly to your error monitoring pipeline. Instead of copying a stack trace out of the Sentry dashboard and pasting it into a chat, the model pulls the full issue, breadcrumbs, environment context, and related events, and works from the actual data.

Sentry runs a production remote server over Streamable HTTP with OAuth 2.1:

{
  "mcpServers": {
    "sentry": {
      "type": "http",
      "url": "https://mcp.sentry.dev/mcp"
    }
  }
}

Your client handles the OAuth sign-in on the first connection. A local stdio option (npx @sentry/mcp-server@latest) is also available if you prefer to run it yourself.

Beyond raw issue retrieval, the server exposes Sentry’s Seer tooling for AI-assisted root cause analysis, so the model can move from “here is the error” to “here is the likely cause and a suggested fix” against real production data.

Debugging use cases

The typical debugging loop is slow, but with the Sentry server, the model gets the same view you do, the complete issue with all context attached. The highest-value query for most teams is the morning check, asking whether any new errors have appeared since the last deploy without opening the dashboard.

const sentryWorkflow = async (client) => {
 const issues = await client.callTool({
   name: 'search_issues',
   arguments: {
     organizationSlug: 'my-org',
     query: 'is:unresolved'
   }
 });
const rootCause = await client.callTool({
name: 'analyze_issue_with_seer',
arguments: {
organizationSlug: 'my-org',
issueId: issues[0].shortId
}
});
return { issues, rootCause };
};

How do you automate browser testing with the Playwright MCP server?

The Playwright MCP server provides browser automation through structured accessibility snapshots rather than pixel-based interaction, which keeps it deterministic and avoids the need for vision models. It supports Chrome, Firefox, WebKit, and Edge in both headless and headed modes.

The basic stdio setup pins to the latest release:

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

For Claude Code, one command does it:

claude mcp add playwright npx @playwright/mcp@latest

A couple of flags are worth knowing. Vision capabilities are enabled through the capabilities flag, --caps vision, and headless mode through --headless. For remote or display-less environments, run the server with a port to enable HTTP transport:

npx @playwright/mcp@latest --port 8931
{
"mcpServers": {
"playwright": {
"type": "http",
"url": "http://localhost:8931/mcp"
}
}
}

Also, for coding agents that have filesystem access, Microsoft now ships a companion @playwright/cli that exposes the same automation as shell commands. It is considerably more token-efficient because it writes snapshots and screenshots to disk instead of streaming them into context.

Testing workflow applications

QA teams generate test suites from application functionality using accessibility snapshots, development teams run cross-browser regression testing, and platform teams script realistic user journeys.

const playwrightTestSuite = async (client) => {
 await client.callTool({
   name: 'browser_navigate',
   arguments: { url: 'https://myapp.com/login' }
 });
const snapshot = await client.callTool({
name: 'browser_snapshot',
arguments: {}
});
await client.callTool({
name: 'browser_type',
arguments: {
element: 'email input field',
ref: 'input[type="email"]',
text: 'test@example.com'
}
});
return { snapshot };
};

How do you secure MCP servers?

Running MCP servers in production carries real security weight, well beyond “store your tokens carefully.” A few things deserve attention.

1. Prompt injection through tool responses – This is the attack that matters most for MCP. Any server that returns external content, web pages, issue text, or documentation is a potential vector for injected instructions. Treat tool output as untrusted data, and be especially careful before granting write access to any server that reads from the open web. Security researchers have flagged this repeatedly through 2026
2. Validate the origin header – The current spec requires servers to validate the Origin header on incoming connections to prevent DNS rebinding attacks, and local servers should bind to 127.0.0.1 rather than 0.0.0.0. If you are running or building a server, confirm this is in place
3. Scope OAuth permissions tightly – Remote servers on Streamable HTTP have largely standardized on OAuth 2.1, which lets you request narrow scopes. Ask for repo:read rather than full repo access, a single project rather than the whole org. Short-lived, narrowly scoped credentials dramatically limit the blast radius when an agent misfires
4. Prefer official and containerized servers – Use the vendor’s own implementation over an unreviewed community fork where one exists, and consider Docker’s MCP Catalog for containerized isolation. A large share of servers scanned in 2026 audits had security findings, so the provenance of what you install genuinely matters. Pin community servers to a known-good version
5. Mind the token budget – Every connected server injects its tool definitions into context, often 500 to 1,000 tokens per tool. Five servers with rich tool sets can consume tens of thousands of tokens before you ask anything. Keep your active set small, three to five servers covering your actual weekly workflow, and use read-only modes and toolset filters to trim what the agent sees

Beyond these, the usual production hygiene is to centralize configuration and secrets, monitor latency and error rates per server, handle timeouts gracefully, and store credentials in environment variables or a secrets manager rather than plain text.

Frequently asked questions

Is SSE still supported in MCP?

The legacy HTTP+SSE transport is deprecated. It was superseded by Streamable HTTP in the 2025 spec, and the current stable spec recognizes only stdio and Streamable HTTP. SSE still works in many clients for backward compatibility, but you should not build anything new on it. If a config points at a /sse URL, move it to the server’s /mcp endpoint.

What is the difference between stdio and Streamable HTTP?

Use stdio when a single client launches the server as a local subprocess on the same machine, with no ports, auth, or CORS to manage. Use Streamable HTTP for anything remote or multi-client, where the server runs independently on a URL and exposes one endpoint that handles both requests and optional streaming responses.

Are MCP servers free?

Most are. The servers here are free to install, and many are free to use within a provider’s free tier, with usage beyond that metered. GitHub MCP is free with a GitHub account, Playwright and the Docker Toolkit are free, and Context7 has a free tier. The real cost of running servers is not money but context window tokens, since each server’s tool definitions consume space in every request.

Do I still need a personal access token, or can I use OAuth?

It depends on the server. Remote servers largely use OAuth 2.1, so GitHub, Figma, Sentry, and Cloudflare typically prompt a browser sign-in on first use. Many also accept a token as a fallback, and local stdio servers usually authenticate through a CLI login or a connection string rather than OAuth.

How many MCP servers should I run at once?

Three to five is the practical sweet spot. Each server adds tools to the agent’s budget, which slows tool selection and raises the chance of the wrong tool being chosen. Install only servers that solve a problem you hit weekly, and lean on read-only modes and toolset filters to keep the surface tight.

Which MCP servers should I install first?

For most web developers, GitHub MCP, Context7, and Playwright cover the majority of what an agent needs: repository context, current documentation, and browser automation. Add the others as specific workflows demand them: a cloud server when you deploy, a database server when the agent needs to reason about data, and Sentry when debugging is eating your time.

Conclusion

The Model Context Protocol marks a major shift in how we build AI-powered applications. The 15 MCP servers covered here form the foundation for creating advanced, integrated workflows, whether you’re analyzing code with GitHub or automating deployments with Cloud Run.

Success with MCP comes from choosing servers that match your actual stack and keeping the set small enough that each one earns its place in the context window. Start with a handful that complement what you already use, scope their permissions tightly, treat their output as untrusted, and expand only when a real workflow demands it.

The post The top 15 MCP servers for your AI projects appeared first on LogRocket Blog.