14 MCP Server Examples With Setup Notes (2026)

14 MCP Server Examples With Setup Notes (2026)

TL;DR: MCP server examples include Supabase for database exploration, GitHub for repository work, Context7 for documentation, Playwright for browser tasks, and a scoped filesystem server for local files. A server can expose read and write tools. Start with one provider, use its current official setup instructions, and review its permissions before approving tool calls.

An MCP server exposes tools and other context to an AI client. These 14 examples cover common use cases, with a link to each provider's setup or source. They are not one tested personal config: authentication, client support, and permissions vary. For Cursor's file locations and connection steps, see Add MCP servers to Cursor. For design decisions, see MCP Server Architecture and MCP vs REST API.

A small Cursor config to start with

Cursor documents global ~/.cursor/mcp.json and project .cursor/mcp.json files. The two hosted entries below support interactive OAuth in compatible clients; the two local entries run with npx. Replace YOUR_PROJECT_REF before connecting Supabase. This is a starter config, not a connection test or a promise that every client handles OAuth identically. Confirm each server in Cursor's MCP settings and inspect the tools it exposes. Sources: Cursor configuration, Supabase setup, AppHandoff endpoint.

{
  "mcpServers": {
    "supabase": {
      "url": "https://mcp.supabase.com/mcp?project_ref=YOUR_PROJECT_REF&read_only=true&features=database%2Cdocs"
    },
    "apphandoff": {
      "url": "https://api.apphandoff.com/api/mcp-bot"
    },
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest", "--isolated"]
    },
    "shadcn": {
      "command": "npx",
      "args": ["shadcn@latest", "mcp"]
    }
  }
}

The Playwright example starts an isolated browser without saved login state. The shadcn server works with registries defined in the project. Both local commands come from their Playwright and shadcn guides. Add only the servers needed for your task; an HTTP URL does not make its tools read-only, and a local command does not make them safe by default.

1. Supabase — query your database in plain English

Use Supabase's hosted server to inspect a project's schema or ask a narrow SQL question. The official setup documents project_ref to limit access to one project, features to limit tool groups, and read_only=true to execute SQL as a read-only user. Read-only is an option you must select; feature filtering alone does not enforce it. Supabase warns that connecting a production project exposes it to the assistant's developer permissions.

Try: "Describe the orders table in the scoped project." Review the returned data before sharing it further.

2. GitHub (official Copilot MCP) — issues, PRs, code search

GitHub hosts its official remote MCP server at https://api.githubcopilot.com/mcp/. A compatible client can obtain a token through OAuth, or supply a valid access token. For repository review, use the documented /readonly endpoint or read-only header and grant the narrowest repository access you can. Toolsets vary by endpoint; do not assume the default includes every GitHub operation.

Try: "Find pull requests that changed this file and summarize the relevant diffs." Check the source PRs before acting on the summary.

3. Context7 — library docs the LLM actually got right

Context7's client guide documents https://mcp.context7.com/mcp with an Authorization: Bearer YOUR_API_KEY header, and /mcp/oauth for clients using OAuth. Its Cursor guide also documents Context7-API-Key as an HTTP header. The former article's CONTEXT7_API_KEY HTTP header was wrong; that name is used for a local environment variable. Keep the key in your client's secret storage or use OAuth where supported.

Try: "Find the current Next.js documentation for route handlers, then cite the relevant page." Check the returned version and source before applying an API change.

4. AppHandoff — handoff tickets between repos

AppHandoff's hosted MCP endpoint is https://api.apphandoff.com/api/mcp-bot. Its published Cursor setup uses that URL and OAuth sign-in, without a pasted bearer token. It exposes shared tickets and project context for agents working across repositories.

Try: "Read the assigned handoff ticket and its acceptance criteria before editing." Ticket changes are write operations; review them before approval.

5. Fly.io — deploy and inspect from chat

Fly's current fly mcp documentation covers launching MCP servers hosted on Fly, configuring a client, and inspecting their tools. That is different from controlling Fly apps through an MCP. The separate superfly/flymcp repository is a Go wrapper around flyctl for Fly operations, with build and authentication steps. The old npx @flydotio/mcp recipe has no matching official setup here, so do not copy it as an app-operations server.

Try: Use Fly's fly mcp inspect to inspect a server you host on Fly. For app logs or deployment operations, follow the separate wrapper's source and review its permissions first.

6. Playwright — browser that the agent can drive

The Playwright MCP can launch a browser and expose navigation, interaction, and page inspection. By default it keeps a persistent browser profile; --isolated starts a fresh session and discards its state when it ends. Use the isolated example above when you do not need an existing login. Playwright also documents attaching to an existing browser, which carries that browser's authenticated state into the agent workflow.

Try: "Open the local preview, check the heading, and capture a screenshot." A screenshot is evidence for what the browser showed, not proof that a full user flow passed.

7. shadcn — the UI component MCP

The shadcn MCP guide documents npx shadcn@latest mcp. It can browse and search registries and install components into a project. A private registry's URL and header references go in components.json; supply credential values through the documented environment-variable references rather than committing them in that file.

Try: "List dialog components in the configured registry." Review source and project conventions before allowing an install.

8. Infisical — secrets without leaking them

Infisical's official MCP server runs with npx -y @infisical/mcp. Its default authentication method is universal auth; access-token mode requires INFISICAL_AUTH_METHOD=access-token and INFISICAL_TOKEN. The tool list includes get-secret, list-secrets, and secret write tools. Do not assume secret values stay hidden from the model: a retrieved value can enter the tool response and conversation. Use a narrowly scoped identity and avoid connecting a vault when the task only needs names.

Try: Decide first whether this task needs secret access at all. A missing key-name check can use a safer, purpose-built inventory path if your organization provides one.

9. Filesystem (local) — the boring one that earns its keep

The MCP filesystem reference server is published as @modelcontextprotocol/server-filesystem. It reads and writes files and accepts allowed directories on its command line. A client that supplies MCP Roots can replace those directories, so inspect the resulting scope with list_allowed_directories. An explicit project path is a starting boundary, not a guarantee if client Roots later expand it.

Try: Start it for one project directory, then ask it to list allowed directories before approving a write. Do not grant your home directory for a single-project task.

10. Postgres (generic, non-Supabase)

The @modelcontextprotocol/server-postgres reference implementation supports schema inspection and SQL queries in read-only transactions. Its repository is archived, so weigh maintenance and security before a new deployment. Use a database account with read-only grants too; an MCP-level read-only transaction is not a substitute for database permissions.

Try: On a nonproduction database, ask for the schema of one table and inspect the SQL before executing a query. Connection strings contain credentials; follow your client's secret handling instructions.

11. Linear — tickets and project context

Linear documents https://mcp.linear.app/mcp, OAuth, and a /readonly endpoint. Choose read-only access when the task only needs ticket or project context.

Try: Read an assigned ticket, then draft a proposed update for review before creating or changing it.

12. Notion — workspace pages

Notion documents an official connector that can read and write workspace pages. Review the accessible workspace and proposed changes before approving writes.

Try: Summarize an accessible project brief and cite its page. Review a draft before asking the server to save it.

13. Slack — conversation context

Slack documents https://mcp.slack.com/mcp, but custom clients need a registered Slack app and OAuth setup; partner clients may provide their own integration. A URL alone will not authorize a workspace.

Try: Read an authorized support thread. Cross-service prompts can move private conversation content between providers, so review the destination before creating a ticket elsewhere.

14. Your own — a bounded internal workflow

Build a custom server when a bounded internal workflow needs discoverable tools across MCP clients. Define the exact read and write actions, authenticate the caller, validate arguments, and return concise results. If only one deterministic integration needs the action, an API call may be simpler. See MCP Server Architecture for design considerations.

Try: Start with one read-only lookup tool and test what the agent sees when the input is invalid or access is denied.

Picking transport: stdio vs HTTP

• stdio — a local process communicates with the MCP client over standard input and output. Good for a local filesystem or project tool; protect the process environment and allowed paths.
• Streamable HTTP — a URL serves a remote MCP connection. Hosted services commonly authenticate with OAuth; some support a supplied token. Check each provider's documented method.

These are MCP's two current official transport families. Transport does not determine the tool's permissions. Choose based on where the server runs and what the client supports.

Setup checklist

• Choose one server and follow its current official installation guide.
• Scope the project, account, and permissions before connecting.
• Keep tokens out of committed config files and chat; use the client's supported secret or OAuth flow.
• Confirm the connection and inspect the actual tool list in Cursor settings.
• Test one read request, then review every write request and its target.

If a server fails to connect, check its documented endpoint, authentication method, and local process logs. A connected status proves initialization; it does not prove that the intended account or permissions were used.

Ready to ship your own?

If an internal workflow still needs its own server after you have tested the existing options, describe the workflow and scope the build.