Source: https://www.hype-stack.dev/stacks/best-mcp-servers-for-claude-code # Best MCP Servers for Claude Code When You Are Building an App > An MCP server is worth adding when it replaces something the agent currently guesses at. Most lists rank them by > popularity. This one ranks them by which guess they remove. Claude Code can read your files, run your tests and call your API without any MCP server at all. The servers earn their place at the edges of the repo: the browser the app renders in, the database it writes to, the issue tracker the work came from, the docs for a library that changed since the model was trained. Every one of those is a place where the agent otherwise works from memory, and memory is where the confident wrong answers come from. This is a list for one job, building a web app. If you want the agent to book flights, this is not it. ## How to judge one Three questions, and a server needs a good answer to all three before it goes in your config. **Before adding a server** - **What does the agent stop guessing?** A docs server stops it guessing an API that changed last month. A browser server stops it guessing whether the page it just built renders. If you cannot name the guess, the server is a toy. - **How much of the context window does it eat?** Every server adds its tool descriptions to every request. A server with forty tools you use twice costs you on every turn. Prefer small servers, and remove the ones you stopped using. - **What can it do without asking?** A server that can push to main, charge a card or drop a table needs the same care as giving a contractor those keys. Read the tool list before you trust it, and keep the destructive ones behind a prompt. _Popularity tells you a server is installed a lot. It does not tell you whether it removes a guess in your project._ ## The list, by the guess it removes **MCP servers for building a web app with Claude Code** - **Playwright MCP** Microsoft's server drives a real browser through accessibility snapshots rather than screenshots, so the agent can open the page it just built, click the button, read the error, and fix it in the same turn. The single biggest change to how useful a coding agent is on frontend work. (browser, e2e, microsoft) - **Chrome DevTools MCP** Google's server gives the agent what you would open DevTools for: console output, network requests, performance traces. Overlaps with Playwright on clicking around, and beats it when the question is why the page is slow or what the failed request returned. (console, network, google) - **Context7** Pulls current documentation for a library into the context on demand. The fix for the agent writing last year's API against this year's package, which is the most common class of bug in agent-written code and the hardest to spot in review. (docs, upstash) - **GitHub MCP** Issues, pull requests, reviews and CI status from inside the session. Useful the moment work arrives as an issue rather than a chat message, and for letting the agent read the review comments on its own PR. (issues, pull requests, github) - **A Postgres server** Lets the agent read the real schema and run real queries instead of inferring tables from the ORM models. Use one that defaults to read-only, such as Crystal DBA's postgres-mcp, and point it at a local database, not production. (schema, queries, read-only) - **Sentry MCP** Hands the agent the stack trace and the breadcrumbs for an error that happened to a real user, which is a better bug report than any human writes. Only matters once the app has users, which is later than most lists admit. (errors, production) - **Linear MCP** The same idea as GitHub issues for teams that track work in Linear: the agent reads the ticket, updates it, and links the PR. Skip it if your tickets are in GitHub. (tickets, linear) - **Figma Dev Mode MCP** Gives the agent the design context for a frame instead of a screenshot of it: spacing, tokens, component names. Worth it only when there is a designer producing Figma files. Without one, it is a tool with nothing to read. (design, tokens, figma) - **Hype Stack MCP** Ours. Eleven tools that scaffold a project from the template, search the pack catalog, plan and run installs, start Docker and migrations, and inspect what a project already has. It exists so the agent composes a real app through the real CLI instead of inventing shell flags. It is not a general-purpose tool and does nothing useful outside a Hype Stack project. (scaffold, packs, migrations) _Roughly in the order a new project needs them. Playwright and a docs server pay for themselves on day one; Sentry and Figma only once there is production traffic or a designer._ ## What you do not need a server for The reference servers for filesystem access and web fetching are the ones every tutorial starts with, and Claude Code does not need them. It reads and edits files natively and fetches URLs natively. Adding them buys duplicate tools and a bigger context. The same goes for a shell server. The agent already runs commands. What it lacks is not access to your machine, it is knowledge of the things your machine cannot see: a browser's rendered state, a library's current docs, a ticket's acceptance criteria. > Add servers for what the agent cannot see, not for what it can already do. ## Wiring them in Claude Code reads MCP servers from two places. User scope lives in your home directory and follows you between projects. Project scope is a `.mcp.json` at the repository root, committed, so everyone who clones the repo gets the same tools. Cursor reads the same idea from `.cursor/mcp.json`; the rest of a working Cursor setup is in [Cursor best practices](/stacks/cursor-best-practices), and procedures belong in [Cursor skills](/stacks/cursor-skills) rather than in a server. Playwright, added at user scope from a terminal: ```bash claude mcp add -s user playwright -- npx -y @playwright/mcp@latest ``` Ours, the same way: ```bash claude mcp add -s user hype-stack -- npx -y @hype-stack/cli@latest mcp ``` Or the project form, which is what a shared repo should carry: ```json { "mcpServers": { "playwright": { "type": "stdio", "command": "npx", "args": ["-y", "@playwright/mcp@latest"] }, "hype-stack": { "type": "stdio", "command": "npx", "args": ["-y", "@hype-stack/cli@latest", "mcp"] } } } ``` Two things the docs for most servers leave out. A server launched by an app opened from the Dock does not have your shell's `PATH`, so a bare `npx` can fail with `spawn npx ENOENT` in Claude Desktop while working fine in the terminal. And servers that need a credential need it in the config's `env` block or in their own store, because there is no terminal to log in from once the editor owns the process. Ours writes the key for you when you run `npx @hype-stack/cli@latest mcp install`; the others each have their own way. ## Where the foundation comes in A browser server tells the agent the page is broken. It does not make the agent good at fixing a codebase it does not understand, and that is the part most MCP lists skip. The projects where these servers pay off are the ones where the agent already has the repository's conventions in front of it. That is what the template is for: it ships rules files in each editor's format (Claude Code reads `.claude/rules/*.md`, scoped by path so backend rules only load on backend files), a set of skills in `.agents/skills`, a typed contract from the Hono backend to the React frontend so a wrong field fails the typecheck instead of the user, and the MCP server above so the agent adds auth, billing or a team workspace through the real installer. **Templates that ship with the rules, skills and MCP server wired** Six starting points, each a working app with accounts, organizations and an admin panel. The agent gets the conventions on day one, and the servers on this page get a codebase worth pointing at. [Browse the templates](https://www.hype-stack.dev/templates) What you still write yourself: the product. The template has no idea what your app does, and no server on this list will tell it. The servers remove guesses about the environment. The rules remove guesses about the code. Neither removes the need to decide what to build. Servers are one layer of the setup; the files that steer the agent are in [Claude Code Templates](/stacks/claude-code-templates), the wider tool map in [Agentic Coding Tools 2026](/stacks/agentic-coding-tools), and a backend worth pointing it at in [Hono Prisma Starter with Postgres, Typed Client and Docker](/stacks/hono-prisma-starter).