mcp server
Not a list of cool MCPs to try — the 12 I actually run in Cursor every day, with the real mcp.json config for each and notes on which transport to pick.
TL;DR — Forget the "universal translator" marketing. An MCP server is a tiny program that exposes
tools/listandtools/callover JSON-RPC so an AI agent can discover and invoke functions in your systems. Below are 12 I actually run (or have shipped for clients) — with the realmcp.jsonconfig to wire each one up, and notes on which transport (stdio vs HTTP) to pick and why.
I run 8 MCP servers in my daily Cursor setup and I build custom ones for clients through AppHandoff. This is not a list of "cool MCPs to try" — it's the set I come back to, plus the config to make them work. If you want the architecture layer, see MCP Server Architecture. For the REST vs MCP decision, see MCP Server vs REST API.
Everything in this post lives in one file: ~/.cursor/mcp.json (or Claude Desktop's equivalent). This is my actual working config, redacted:
{
"mcpServers": {
"Supabase": {
"url": "https://mcp.supabase.com/mcp?project_ref=<ref>&features=database%2Cdocs"
},
"GitHub": {
"url": "https://api.githubcopilot.com/mcp/",
"headers": { "Authorization": "Bearer ${input:github_mcp_pat}" }
},
"Context7": {
"url": "https://mcp.context7.com/mcp",
"headers": { "CONTEXT7_API_KEY": "${env:CONTEXT7_API_KEY}" }
},
"AppHandoff": {
"url": "https://apphandoff.com/api/mcp",
"headers": { "Authorization": "Bearer ${env:APPHANDOFF_TOKEN}" }
},
"Fly": { "command": "npx", "args": ["-y", "@flydotio/mcp"] },
"Playwright": { "command": "npx", "args": ["-y", "@playwright/mcp@latest"] },
"Shadcn": { "command": "npx", "args": ["shadcn@latest", "mcp"] },
"Infisical": {
"command": "npx", "args": ["-y", "@infisical/mcp"],
"env": { "INFISICAL_TOKEN": "${env:INFISICAL_TOKEN}" }
}
}
}
Two transports: HTTP (url + headers) for hosted servers and stdio (command + args) for local processes. Use HTTP when the server is multi-tenant with its own auth. Use stdio when the server needs direct access to your machine (your filesystem, your local dev env, npm registry).
Below, the 12 I actually recommend.
Supabase's official MCP (mcp.supabase.com/mcp) gives an agent read access to your Postgres schema + docs. "What's the current row count on blog_posts where site_id = 'inspired'?" becomes a one-line chat command. Feature flags (features=database,docs) let you scope exactly what the agent can touch — read-only by default.
When to use it: debugging, schema exploration, dashboards you haven't built yet.
api.githubcopilot.com/mcp/ is the official GitHub MCP. Bearer token auth, multi-tool surface (issues, PRs, code search, actions status). The kill feature is code search across every repo you have access to — way faster than clicking around GitHub.
Real workflow: "find the last PR that touched mcp-foreign.ts and summarize the changes." Five seconds.
Context7 indexes documentation for ~10k libraries (Next.js, Supabase, Stripe, React, etc.) and exposes resolve-library-id + get-library-docs as tools. The agent pulls the exact version of the docs you need, so you stop getting hallucinated API signatures from 18 months ago.
Why this one matters: 80% of the "AI wrote wrong code" complaints I see in 2026 are stale-docs problems. This fixes most of them.
This is one of mine. When the backend agent needs FE work (new marketing page, new form), the backend calls report_handoff_request via AppHandoff's MCP and the FE agent picks it up. Same tokens, same tool surface, both agents speak it.
Why it works as MCP: the action is agent-to-agent coordination — exactly the space where MCP beats a REST wrapper. See MCP vs REST API for the decision logic.
@flydotio/mcp exposes app lifecycle tools (list apps, scale machines, tail logs, set secrets). I run my backend on Fly (inspired-api.fly.dev) and this MCP removes the need to context-switch to a terminal for 80% of ops.
Favorite command: "tail prod logs for 60 seconds and tell me if anything 5xx'd."
@playwright/mcp spawns a real Chromium and exposes navigation, clicks, form fills, screenshots as tools. This is the one I reach for when the agent needs to verify something ("is this checkout page rendering the price correctly?"), not just read static HTML.
Why it's different from Chrome MCP: Playwright is headless-first and cleaner for CI/eval loops. Chrome MCP is better for driving your already-open browser.
shadcn@latest mcp lets the agent list components, fetch source, and drop them into your project. It's the fastest way I've found to scaffold a new admin panel — the agent reads which components exist, picks the right one, writes the import.
Secrets management via MCP sounds terrifying until you realize the agent never sees the values — just the names and metadata. It can tell you "this app is missing STRIPE_WEBHOOK_SECRET in prod" without ever loading the secret into context.
Why this matters: cheaper than your production outage at 2am when the one secret you forgot rotates.
The official @modelcontextprotocol/server-filesystem exposes read/write on a scoped directory. Pair it with a project-specific scope and you have a safer version of "let the agent write files directly."
Trap to avoid: don't scope it to ~. Scope it to the project root. Every MCP that writes files should be able to only reach the project.
Same pattern as Supabase MCP but for any Postgres. @modelcontextprotocol/server-postgres with a read-only connection string is the version I trust in production. If you're building RAG over structured data, this plus an embeddings table beats most vector DBs for the first 6 months.
If your team lives in Linear, Notion, or Slack, the official MCPs for each are table stakes now. "Summarize last week's #support channel and file any recurring issues as Linear tickets" is a 20-second command that used to be a 45-minute human task.
The 12th MCP on this list is the custom one you build for the workflow that lives only in your company. Internal CRM? Custom admin? Proprietary pricing engine? If an agent should touch it and you want multiple clients (Claude + Cursor + a custom agent) to reach it, MCP is the right shape.
See MCP Server Architecture for the production checklist: rate limiting, circuit breakers, response caps, structured errors. Don't ship without those.
Start stdio when you're prototyping on your own machine. Move to HTTP when anyone else needs to call it.
~/.cursor/mcp.json (or Claude Desktop config)${env:NAME} — never inlinetools/list succeededIf you get a red dot: check the server's logs first, not the config. 9/10 of the time it's a missing env var.
If you have an internal system that should speak MCP — CRM, ops tool, pricing engine, internal analytics — describe it and I'll scope the build. I've shipped this stack in production and maintain several of the MCPs above.
// keep reading
mcp server · 8 min
Four layers every production MCP server needs — transport, JSON-RPC shape, tool definitions, and guardrails. With real code for rate limiting, circuit breakers, and structured errors.
mcp server · 7 min
The actual working config for ~/.cursor/mcp.json — two transports, env-var secrets, the 5-minute setup flow, and the debugging loop for the red dot.