For frontend work, I want MCP servers that improve four things: current technical knowledge, understanding of the running application, accurate implementation from design, and proof that the interface works.
The core setup is Context7, BrowserMCP, Framelink, shadcn MCP, framework devtools, and Playwright MCP. Each earns its place by removing a specific kind of frontend guesswork.
Global vs. project scope
Use global scope for tools that are useful across repositories and do not expose a specific project’s code, runtime, or data.
Use project scope for anything attached to a particular repository, development server, test suite, or production-adjacent system.
Context7: live documentation, not remembered documentation
Context7 should be global.
It brings current framework and package documentation to the agent, stopping a common failure mode: confidently using an API that existed in an older version, was deprecated, or now behaves differently.
Use it for React, Next.js, Angular, shadcn/ui, and any package where exact APIs or configuration matter.
It answers a simple question: “What is the current supported way to do this?”
Context7 does not replace reading the repository. It tells the agent how the framework works today; the project tells it how the team uses that framework.
BrowserMCP: inspect the real browser
BrowserMCP should be global.
BrowserMCP controls the actual browser, including existing authenticated sessions. That makes it useful for inspecting real workflows rather than only an isolated local test environment.
- Inspect live application behavior.
- Reproduce a reported issue.
- Navigate authenticated internal tools.
- Validate workflows that depend on an existing login session.
- Check a design or content system in its real environment.
Its strength is realism: it sees what the developer sees. Because it can access active sessions, it should be treated carefully—especially around production systems and actions that make changes.
Framelink: Figma to code without guesswork
Framelink should be globally available, with access limited to the relevant files or team.
Frontend implementation loses too much time to eyeballing: estimating spacing, guessing text styles, missing component states, and rebuilding a design from screenshots.
Framelink brings Figma structure into the development workflow. The goal is not to mechanically translate every pixel into code. The goal is to understand the design system: layout, typography, spacing, tokens, variants, responsive intent, and component states.
- Build a new screen from Figma.
- Match an existing component to its source of truth.
- Identify states that are unclear in a static screenshot.
- Translate design tokens into the application’s UI system.
shadcn MCP: use components correctly
shadcn MCP should be global.
When a project uses shadcn/ui, the agent should not keep consulting docs or inventing component APIs from memory. shadcn MCP provides the correct component patterns, installation guidance, and composition details when needed.
- Select the appropriate component.
- Add components using the project’s established approach.
- Check accessibility and composition patterns.
- Avoid hand-rolling a dialog, dropdown, form control, or data table that already exists in the system.
It does not replace design judgment. It makes implementation faster, more consistent, and less error-prone.
Next.js DevTools: understand the running app
Next.js DevTools should be project-scoped.
Context7 tells the agent how current Next.js works. Next.js DevTools shows how this specific application behaves while it is running.
Use it before changing an existing feature, especially when the task involves routes, runtime errors, data loading, caching, server/client component boundaries, or existing behavior that is unclear.
This prevents a frequent mistake: making a technically valid change in the wrong part of the application.
Playwright: verify the user experience
Playwright MCP should be project-scoped.
A frontend change is not complete because TypeScript passes or the application compiles. It is complete when the relevant experience works in a browser.
- Open the affected route.
- Exercise the intended flow.
- Test forms, navigation, menus, dialogs, and loading states.
- Check responsive behavior.
- Detect console and network failures.
- Run existing end-to-end tests.
- Capture screenshots when visual confirmation matters.
Playwright belongs with the project because its configuration, base URL, fixtures, and browser assumptions are repository-specific.
The React setup
- Context7 globally for React and package documentation.
- BrowserMCP globally for real-browser inspection.
- Framelink globally, scoped to relevant designs.
- shadcn MCP globally when the project uses shadcn/ui.
- Playwright in the project for end-to-end verification.
React’s flexibility makes disciplined verification important: understand the existing patterns, make the smallest useful change, and verify it in a browser.
The Next.js setup
- Context7 globally for current React and Next.js documentation.
- BrowserMCP globally for authenticated or live-environment inspection.
- Framelink globally for design implementation.
- shadcn MCP globally when relevant.
- Next.js DevTools in the project for runtime diagnostics.
- Playwright in the project for browser verification.
This creates a complete workflow: current docs → design source → running app → real browser → repeatable tests.
The Angular setup
- Context7 globally for Angular APIs, CLI conventions, and current patterns.
- BrowserMCP globally for real-browser inspection.
- Framelink globally for design handoff.
- Playwright in the project for end-to-end testing.
- shadcn MCP only when it is genuinely part of the stack; shadcn/ui is primarily React-oriented.
Angular teams benefit from tools that respect existing conventions rather than introducing a parallel architecture. Context7 provides current guidance, and browser tools confirm the result works for users.
The opinionated baseline
Start most frontend projects with Context7 for live documentation, BrowserMCP for real browser behavior, Framelink for Figma implementation, shadcn MCP for components, Next.js DevTools for Next.js runtime diagnostics, and Playwright for repeatable browser verification.
The best MCP setup is not the largest one. It is the one that carries a frontend change from accurate guidance, to correct design, to verified browser behavior with the least guessing.
