Agentbrisk

Real-World MCP Server Workflows for Claude Code and Cursor in 2026

May 5, 2026 · Editorial Team · 8 min read · mcpclaude-codecursor

MCP (Model Context Protocol) was Anthropic's bet that the way to make AI coding tools more powerful wasn't to bake more capabilities into the model, but to give it a standard way to call external tools and data sources. Twelve months into the ecosystem building out, that bet looks right.

The number of available MCP servers has grown from a handful of Anthropic-maintained references to several hundred community-maintained servers covering everything from database access to Figma integration to Stripe API management. But quantity isn't the point. What matters is whether the integrations that actually exist solve real workflow problems.

Here's what's actually useful in practice, with specific configurations.

How MCP servers work in these tools

The quick version: an MCP server is a process that runs on your machine and exposes tools to the AI editor through the MCP protocol. The editor (Claude Code, Cursor, Windsurf) can call these tools as part of its task execution. From the model's perspective, an MCP tool looks like any other tool in its toolkit: a name, a description, and parameters.

The difference from built-in tools is that MCP tools run in your environment, with your credentials, with access to your systems. A GitHub MCP server uses your personal access token. A database MCP server connects to your actual database. This is powerful and it means you need to think about permissions.

Claude Code has native MCP support configured in ~/.claude/settings.json (global) or .claude/settings.json (project-level).

Cursor added MCP support in version 0.45 (late 2025). It's configured in ~/.cursor/mcp.json.

Windsurf supports MCP through its extension system with configuration in ~/.codeium/windsurf/mcp_config.json.

The configuration format is similar across all three. The examples below use Claude Code's format; the structure translates directly.

GitHub MCP: the one you'll use most

The GitHub MCP server is the most practically useful MCP integration for most developers. It gives the agent the ability to create issues, read PR comments, check workflow status, and search code in GitHub repositories.

Install and configure:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_yourtokenhere"
      }
    }
  }
}

Your token needs repo scope for private repositories and public_repo for public ones. For CI/CD status checking you also need workflow scope.

Workflow 1: PR review comment resolution

The workflow I use most: find an open PR, read the review comments, and have Claude Code apply the changes.

Using the GitHub MCP, read the review comments on PR #247 in the owner/repo repository. 
Then apply the suggested changes to the local files. After making each change, confirm 
which comment you're addressing.

The agent uses get_pull_request_comments to retrieve the comments, maps them to files in the local repository, and applies the edits. This turns an hour of manually working through review comments into a 10-minute process with human review at the end.

Workflow 2: Issue-to-implementation

Read GitHub issue #183 in owner/repo and implement the feature described. 
Create the implementation following CLAUDE.md conventions. 
When done, summarize the changes made so I can use them as a PR description.

This only works well when the issue is well-specified. Vague issues produce vague implementations. But for issues that have been properly scoped by a product manager or tech lead, this is a genuine workflow accelerator.

Workflow 3: CI failure debugging

The workflow run at github.com/owner/repo/actions/runs/12345678 failed. 
Using the GitHub MCP, read the workflow logs for the failing steps and then 
identify the likely cause in the local codebase.

The agent reads the GitHub Actions logs via MCP, finds the error, locates the relevant code, and proposes a fix. This saves the context-switching cost of reading CI logs in a browser tab and then manually copying error messages into the chat.

Filesystem MCP: finer-grained access control

Claude Code has built-in file access, but the filesystem MCP server gives you more precise control over which paths the agent can access. It's most useful in monorepo setups where you want to restrict the agent to specific packages.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/yourname/projects/myapp/packages/api",
        "/Users/yourname/projects/myapp/packages/shared"
      ]
    }
  }
}

The path arguments restrict access to those directories only. This is useful for security (the agent can't accidentally read .env files outside the specified paths) and for focus (the agent isn't indexing your entire monorepo when you only want it to work on one package).

In Cursor specifically, this complements the .cursorignore file. The ignore file tells Cursor what not to index for search/autocomplete; the filesystem MCP tells the agent what it can access when you explicitly ask it to read or write files.

Playwright MCP: browser automation for real tasks

The Playwright MCP server is the tool that makes AI editors genuinely useful for frontend debugging. It lets the agent open a browser, navigate to pages, take screenshots, click elements, and read the DOM.

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

Workflow 1: Visual CSS debugging

Instead of describing a layout problem ("the button is 4px too far to the right"), you can point Claude Code at your local dev server and have it see the problem:

Open http://localhost:3000/dashboard in the browser using Playwright MCP.
Take a screenshot and identify any visual layout issues on the page.
Then look at the relevant CSS files and fix whatever is causing the issues.

The agent navigates to the URL, takes a screenshot (which it can actually see, Claude 4 Sonnet being multimodal), identifies the layout problem, reads the CSS, and proposes a fix. This is dramatically faster than the describe-attempt-describe cycle.

Workflow 2: E2E test generation from live interaction

Navigate to http://localhost:3000/signup and complete the signup flow. 
After each step, describe what action you took and what you observed.
Then generate a Playwright test file that reproduces this exact flow.

The agent interacts with your actual app and writes tests based on real interaction. The resulting tests are more accurate than tests written from reading the code alone, because the agent has actually exercised the real behavior.

Workflow 3: API response inspection

The Playwright MCP can intercept network requests. This is useful for checking that your API is returning the correct data when debugging a frontend issue:

Navigate to http://localhost:3000/products and intercept the API calls made during page load. 
Report the full response from the /api/products endpoint, including headers and response body.

Postgres MCP: schema-aware query writing

Database MCP servers give the agent direct read access to your database. This is powerful for schema-aware code generation and query writing.

A typical setup using the community @modelcontextprotocol/server-postgres:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://localhost:5432/myapp_development"
      ]
    }
  }
}

Important: Point this at your development database, not production. The server defaults to read-only mode, but you don't want to take any chances with production data.

Workflow: Generate accurate TypeScript types from schema

Using the Postgres MCP, read the schema for all tables in the public schema. 
Then generate TypeScript interfaces for each table that match the exact column names and types.
Put the result in /types/database.ts, replacing the current file.

Without the MCP, you'd copy-paste schema definitions from \d tablename in psql. With it, the agent reads the schema directly and generates types that are guaranteed to match.

Workflow: Write a complex query from a business requirement

I need a query that shows monthly active users over the last 6 months, 
grouped by plan type. Use the Postgres MCP to look at the users and events tables, 
understand the structure, and then write the query.

The agent examines the actual table structure before writing the query. This avoids the common problem of getting a query that looks right but uses column names that don't exist.

Windsurf-specific MCP considerations

Windsurf (built on the VS Code fork by Codeium) has MCP support with some differences from Claude Code. The main one: Windsurf uses its own AI model (a fine-tuned variant of Claude 4 Sonnet as of May 2026) rather than the raw Anthropic API, so MCP tool call behavior is slightly different.

In practice, the GitHub and filesystem MCP servers work well in Windsurf. The Playwright MCP works with some limitations (screenshot interpretation is less reliable in the Windsurf context). The Postgres MCP works but the generated SQL sometimes needs adjustment for edge cases in complex schemas.

For Windsurf's MCP config:

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

Practical MCP hygiene

A few things I've learned running multiple MCP servers simultaneously:

Start each MCP server manually before a session. Some servers have initialization time and if the AI editor tries to call a tool before the server is ready, you get cryptic errors. Run npx @modelcontextprotocol/server-github in a terminal first, confirm it starts, then open your editor.

Use project-level MCP config for project-specific servers. The Postgres MCP for your development database should live in .claude/settings.json (project level), not ~/.claude/settings.json (global). You don't want the development database MCP active when you're working on a different project.

Log MCP tool calls. In Claude Code, you can see each MCP tool call in the session output. Review them, especially for write operations. The GitHub MCP can create issues and comment on PRs; make sure it's doing what you intended.

Rate limits matter. The GitHub API has rate limits. If you're running multiple agents using the GitHub MCP in parallel (e.g., using Claude Code sub-agents), you'll hit those limits. Use a GitHub App token instead of a personal access token for higher rate limits in production workflows.

The MCP ecosystem is still growing. The quality of community-maintained servers varies widely. Before adopting a new MCP server, check: Is it actively maintained? Does it have a defined permission model? Does it log what it's doing? The answers tell you a lot about whether it's safe to run in your development environment.

The four I've described here (GitHub, filesystem, Playwright, Postgres) cover the majority of practical use cases for most developers. Start there and add others only when you have a specific workflow gap they'd fill.

Search