mcp server
12 Real MCP Server Examples You Can Actually Use (2026)
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.
12 Real MCP Server Examples You Can Actually Use (2026)
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.
The one config file that runs them all
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.
1. Supabase — query your database in plain English
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.
2. GitHub (official Copilot MCP) — issues, PRs, code search
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.
3. Context7 — library docs the LLM actually got right
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.
4. AppHandoff — handoff tickets between repos
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.
5. Fly.io — deploy and inspect from chat
@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."
6. Playwright — browser that the agent can drive
@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.
7. shadcn — the UI component MCP
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.
8. Infisical — secrets without leaking them
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.
9. Filesystem (local) — the boring one that earns its keep
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.
10. Postgres (generic, non-Supabase)
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.
11. Linear / Notion / Slack — the "my company runs on this" tier
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.
12. Your own — the one you should build
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.
Picking transport: stdio vs HTTP in 30 seconds
- stdio — the MCP runs as a child process of the agent. Good for tools that need local access (filesystem, node_modules, your dev env). One user, one process.
- HTTP (streamable) — the MCP runs as a server you can host. Required when multiple users (or multiple agents across machines) call the same MCP. Bearer auth in headers.
Start stdio when you're prototyping on your own machine. Move to HTTP when anyone else needs to call it.
Setup checklist
- Create
~/.cursor/mcp.json(or Claude Desktop config) - Add one HTTP MCP + one stdio MCP to prove both transports work
- Put secrets in env vars, reference them as
${env:NAME}— never inline - Restart Cursor / Claude Desktop after every edit
- Hover the green dot in the MCP settings to confirm
tools/listsucceeded - Ask the agent "what MCP tools do you have?" to sanity-check discovery
If 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.
Ready to ship your own?
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.