Best MCP Servers for Remix Developers
The essential MCP servers for Remix development — Supabase for database, Playwright for testing, Cloudflare for deployment, and more. Curated stack with config.
If you search for "MCP servers for Remix," you mostly get results about Remix Icon -- the icon library. That tells you something: the Remix web framework community has not caught up with MCP yet, which means there is a real opportunity to get your development workflow significantly ahead of the curve.
Remix is a full-stack framework built around web standards. It handles routing, data loading, form mutations, error boundaries, and deployment to edge runtimes. The development experience involves working across server loaders, client components, database queries, and deployment targets simultaneously. That is a lot of context switching, and it is exactly the kind of workflow that MCP servers are built to streamline.
This guide covers the five MCP servers that cover a Remix developer's core workflow, how they fit together, and a ready-to-copy configuration for your editor.
Why Remix Developers Need a Different MCP Stack
Remix is not Next.js. It leans heavily on web platform primitives -- Request, Response, FormData, Headers -- rather than framework-specific abstractions. It runs on Cloudflare Workers, Deno, Node, and other runtimes. Its data loading model uses loader and action functions that blur the line between frontend and backend.
This means the MCP servers that work well for a Next.js developer are not necessarily the right fit. You need servers that understand edge deployment, that can interact with your database directly, and that can test the full request-response cycle of your loaders and actions -- not just the rendered UI.
1. Supabase MCP -- Your Database, Inside Your Editor
Author: Supabase (official) | Tools: 25 | Context cost: ~12,875 tokens
Remix applications almost always talk to a database. Whether you are using Supabase directly, Postgres through Prisma, or another data layer, the Supabase MCP server gives your AI assistant direct access to your database schema and data.
The value here is immediate. When you are writing a Remix loader function that queries your database, your assistant can see the actual table structure, column types, and relationships. It does not have to guess or rely on type definitions that might be out of date. It can run queries against a development branch, apply migrations, and verify that the data your loader returns matches what the UI expects.
For Remix specifically, this server shines when you are building forms with action functions. Your assistant can see the database schema, write the mutation query, validate the form data shape against the actual columns, and generate the corresponding loader to refetch the updated data -- all in one pass because it has real access to the database.
If you are not using Supabase, the Postgres MCP server provides similar database access at a lower token cost (~4,200 tokens). The core benefit is the same: direct database context eliminates guesswork.
Configuration
{
"mcpServers": {
"supabase": {
"command": "npx",
"args": ["-y", "@supabase/mcp-server-supabase@latest"],
"env": {
"SUPABASE_ACCESS_TOKEN": "<your-token>"
}
}
}
}
2. Playwright MCP -- Test the Full Remix Request Cycle
Author: Microsoft | Tools: 20 | Context cost: ~5,000 tokens
Remix applications have a tight coupling between server-side loaders and client-side rendering. A bug in a loader function can produce a blank page or incorrect data, and you will not catch it by reading the code alone. You need to actually run the app and verify the output.
Playwright MCP gives your assistant control over a real browser. It can navigate to your running Remix app, interact with forms (which Remix handles through its action function pattern), verify that loaders return the expected data, and check that error boundaries display correctly when a loader throws.
This is particularly useful for testing Remix's progressive enhancement story. Your assistant can test a form submission both with JavaScript enabled (client-side navigation) and with JavaScript disabled (full document request), verifying that the behavior is correct in both cases. That is something most developers skip during manual testing, and it is where Remix's web standards approach really matters.
The accessibility snapshot feature is also worth highlighting. Instead of working from screenshots, Playwright MCP reads the page as a structured accessibility tree. This means your assistant can verify that your Remix app's heading hierarchy, form labels, and ARIA attributes are correct -- catching accessibility issues as part of your normal development flow.
Configuration
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["-y", "@playwright/mcp"]
}
}
}
No API keys required. Runs locally, launches a browser on demand.
3. Cloudflare MCP -- Deploy to the Edge Without Leaving Your Editor
Author: Cloudflare (official) | Tools: 25 | Context cost: ~10,000 tokens
Remix and Cloudflare Workers are a natural pairing. Cloudflare is one of the primary deployment targets for Remix, and many Remix projects use Cloudflare's ecosystem: Workers for compute, D1 for SQLite at the edge, KV for key-value storage, R2 for object storage, and Queues for background jobs.
The Cloudflare MCP server gives your assistant direct access to your Cloudflare account. It can manage Workers, query D1 databases, read and write to KV namespaces, manage R2 buckets, and check deployment status. For a Remix developer deploying to Cloudflare, this means your assistant can help you debug production issues, check your D1 database state, and manage your deployment configuration without you opening the Cloudflare dashboard.
Where this server really earns its place is during the deployment and debugging cycle. When your Remix app works locally but fails on Cloudflare Workers, the issue is usually related to the edge runtime environment -- missing Node APIs, different global objects, or D1 query differences from local SQLite. Your assistant can check the Worker logs, query the D1 database, and compare the production environment against your local setup.
Configuration
{
"mcpServers": {
"cloudflare": {
"command": "npx",
"args": ["-y", "@cloudflare/mcp-server-cloudflare"],
"env": {
"CLOUDFLARE_API_TOKEN": "<your-token>"
}
}
}
}
Requires a Cloudflare API token with appropriate permissions for the services you want to access.
4. Context7 MCP -- Current Remix Docs, Not Stale Answers
Author: Upstash | Tools: 2 | Context cost: ~2,000 tokens
Remix has gone through significant changes in recent years. The transition from Remix v1 to v2 changed the routing convention, the way meta tags work, and the approach to CSS. If your AI assistant's training data predates these changes, it will write code that does not work with modern Remix.
Context7 MCP solves this by pulling live documentation directly from library sources. When your assistant needs to know how defer works in Remix v2, or what the current convention is for route modules, it queries Context7 and gets the current documentation rather than relying on potentially outdated training data.
This is especially important for the Remix ecosystem because the framework has a smaller community footprint than Next.js or React. There is less Stack Overflow content, fewer blog posts, and a thinner training data corpus for AI models. Context7 compensates for this by ensuring your assistant has access to the authoritative source -- the actual Remix documentation.
The server has just two tools and costs roughly 2,000 tokens. For the accuracy improvement it provides, that is an extremely efficient use of your context window.
Configuration
{
"mcpServers": {
"context7": {
"command": "npx",
"args": ["-y", "@upstash/context7-mcp@latest"]
}
}
}
No API key required.
5. GitHub MCP -- Source Control and Community Knowledge
Author: GitHub (official) | Tools: 20 | Context cost: ~8,000 tokens
GitHub MCP provides your assistant with direct access to the GitHub API for managing repositories, pull requests, issues, and code search. Every Remix developer needs this for day-to-day source control, but the real value is less obvious: searching the Remix repository and community packages for solutions to specific problems.
When you hit an issue with Remix's streaming implementation or a specific loader pattern, your assistant can search the Remix GitHub repo for related issues and pull requests. This is faster than manually browsing GitHub and more targeted than a general web search, because the assistant can filter by labels, read full issue threads, and synthesize the relevant information.
Configuration
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "<your-token>"
}
}
}
}
Token Budget: What This Stack Costs
Running every MCP server at once is tempting but wasteful. Here is what this Remix stack costs in context window space:
| Configuration | Servers | Estimated Tokens | % of 200K Context |
|---|---|---|---|
| Lean (Context7 + Playwright) | 2 | ~7,000 | 3.5% |
| Standard (+ Supabase + GitHub) | 4 | ~27,875 | 13.9% |
| Full (+ Cloudflare) | 5 | ~37,875 | 18.9% |
The lean stack gives you current docs and browser testing at just 3.5% of the context window. The standard stack covers database and source control. The full stack adds Cloudflare deployment management.
Start lean and add servers as your workflow demands them.
Ready-to-Copy Configuration
Here is the full Remix MCP stack configured for any client that uses JSON config (Claude Code, Cursor, etc.):
{
"mcpServers": {
"supabase": {
"command": "npx",
"args": ["-y", "@supabase/mcp-server-supabase@latest"],
"env": { "SUPABASE_ACCESS_TOKEN": "<your-token>" }
},
"playwright": {
"command": "npx",
"args": ["-y", "@playwright/mcp"]
},
"cloudflare": {
"command": "npx",
"args": ["-y", "@cloudflare/mcp-server-cloudflare"],
"env": { "CLOUDFLARE_API_TOKEN": "<your-token>" }
},
"context7": {
"command": "npx",
"args": ["-y", "@upstash/context7-mcp@latest"]
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "<your-token>" }
}
}
}
Workflow: Building a Full Feature in Remix
To see how these servers work together, walk through a real scenario.
You are adding a user settings page to your Remix app deployed on Cloudflare Workers. You need a loader to fetch the user's current settings from D1, an action to handle the form submission, a UI with proper form validation, and a deployment to staging.
Context7 pulls the current Remix docs for loader, action, and useFetcher patterns. Supabase MCP (or your database server) shows you the user settings table schema. Your assistant writes the loader, action, and component using the correct Remix v2 conventions and the actual column names from your database. Playwright opens your local dev server, navigates to the settings page, fills out the form, submits it, and verifies the data was saved correctly. Once everything looks good, Cloudflare MCP helps you check the Worker configuration and verify the deployment.
That entire cycle happens within your editor. No browser tabs for docs, no database dashboard, no Cloudflare console.
Getting Started
Pick the servers that match your current pain points:
- Writing loaders and actions with the wrong API? Start with Context7 MCP.
- Testing forms manually in the browser? Add Playwright MCP.
- Guessing at your database schema? Supabase MCP gives you direct access.
- Deploying to Cloudflare and debugging edge issues? Cloudflare MCP handles that.
Each server is a few lines of JSON. Add them incrementally, and drop any that are not pulling their weight. The goal is a focused stack that covers your actual Remix workflow.
For pre-built stacks covering Remix and other frameworks, visit stackmcp.dev. Pick your role, choose your client, and get a config you can paste directly into your editor.