7 Best MCP Servers for Claude Code: Setup Guide

The best MCP servers for Claude Code are the ones that supply context your task actually needs: GitHub for repository work, Supabase or a maintained Postgres integration for database context, Linear for an existing issue workflow, Playwright for browser exploration, and AppHandoff for handoffs between coding agents. Filesystem MCP is a specialist option; ordinary local file work already fits Claude Code’s built-in tools. Start with one missing capability, then add another only when a real task needs it.

This is a documentation-based selection guide for developers coordinating coding agents, not a speed benchmark or a claim that we tested every integration. AppHandoff publishes this article and appears in the list. Our recommendation is conditional: use your existing tracker when it already captures the brief, owner, decisions, and proof. Add shared handoff tooling when those facts keep disappearing between sessions.

Which of the seven MCP servers should you choose?

Use this seven-option selection list as a task, provider/server, access boundary, and first-proof matrix. The provider links and setup details appear below. A documentation check is not a successful login or hands-on benchmark.

• Task: repository issue or PR context | Provider/server: GitHub MCP | Access: authenticated repository permissions; narrow toolsets where supported | Proof: read a known issue and confirm repository and number.
• Task: PostgreSQL schema question | Provider/server: Neon hosted MCP for a Neon Postgres project (or another maintained provider integration) | Access: named development project with readonly=true; confirm effective permissions | Proof: read a known table and constraint without changing data.
• Task: Supabase project context | Provider/server: Supabase MCP | Access: specific project_ref and read_only=true for investigation | Proof: read a known development-project object and confirm its project reference.
• Task: existing Linear issue | Provider/server: Linear MCP | Access: authenticated workspace through the documented /mcp/readonly endpoint for a read task | Proof: read a known issue and confirm workspace and identifier.
• Task: interactive browser investigation | Provider/server: Playwright MCP, optional where a CLI already covers the job | Access: intended browser profile and site permissions | Proof: reproduce one named flow and record observed output; an unpinned package command is not reproducible team setup.
• Task: file operations through MCP | Provider/server: Filesystem MCP, optional where Claude Code's native file tools suffice | Access: inspect effective allowed directories after client roots are applied | Proof: read a known allowed file and confirm out-of-scope paths remain inaccessible.
• Task: shared agent handoff | Provider/server: AppHandoff MCP (our product) | Access: authenticated account and intended project; current rules govern writes | Proof: bootstrap and read a known ticket, then verify its project and reference.

For a single-repository change, the terminal and an existing CLI may be enough. For a frontend/backend handoff, a useful starting combination is the repository source, one task authority, and browser evidence. Add database access only if the ticket requires it. Our MCP developer guide explains the protocol; the MCP server examples guide covers other use cases.

How do you add an MCP server to Claude Code?

Anthropic’s Claude Code MCP reference documents HTTP connections, local subprocesses, and installation scopes. Use explicit transport flags. Project scope writes shared configuration to .mcp.json; user scope makes a server available across your projects. The default local scope is private to you in the current project. Use /mcp inside Claude Code to inspect the connection and authenticate where supported.

# Read-only Linear example; shared project connection definition
claude mcp add --transport http --scope project linear https://mcp.linear.app/mcp/readonly

# Inspect registered connections
claude mcp list

# Inside Claude Code, check status and authentication
/mcp

Adding a server is not proof that it works for your task. Ask it to read one known item, then check that the returned project and identifier are correct. Keep credentials out of committed configuration. A shared connection definition does not give teammates your account access; each person must authenticate with their own permissions. Review a repository’s MCP configuration before approving it, just as you would review a script it asks you to run.

1. GitHub MCP: repository and pull-request context

Use GitHub’s official MCP server for repository, issue, and pull-request operations. Its hosted endpoint is https://api.githubcopilot.com/mcp/. Follow the linked Claude installation instructions for authentication: OAuth availability depends on the host, and personal-access-token configurations need appropriate permissions. The local server also supports read-only mode and tool selection.

A useful first request is: “Read the linked issue and pull request. Summarize the acceptance criteria, changed interface, and unresolved review comments before editing.” This makes the repository record the source for the work instead of relying on a pasted summary. If your team already exposes the same workflow through an authenticated GitHub CLI, decide whether a second interface adds anything. Do not assume that connecting GitHub makes the agent’s local checkout current.

# Register the hosted server; complete the documented authentication setup
claude mcp add --transport http github https://api.githubcopilot.com/mcp/

2. PostgreSQL MCP: choose a maintained provider integration

There is no single universal Postgres MCP server for every database. For a Neon Postgres project, Neon's maintained hosted MCP server is one named option; its project-scoped read-only URL is shown below. Use a different maintained provider integration for a non-Neon database. The original PostgreSQL reference server lives in the archived servers repository; do not use its old @modelcontextprotocol/server-postgres installation recipe as a new default.

# Example for a Neon development project; replace YOUR_DEV_PROJECT_ID
claude mcp add --transport http neon "https://mcp.neon.tech/mcp?projectId=YOUR_DEV_PROJECT_ID&readonly=true"

# In Claude Code: /mcp to authorize and inspect the connection

Neon says its MCP server is for development and testing. After authorizing, confirm the selected project and read one known table and constraint; record the returned evidence. The readonly=true URL narrows the server's operations, but verify the effective account and project scope too. Avoid exposing customer records merely to discover column names, and keep migrations in the reviewed deployment process. This is a proposed setup and first read, not a connection we ran.

3. Supabase MCP: project-scoped backend context

For a Supabase project, the official Supabase MCP documentation is the starting point. Its hosted server supports project scoping and read_only=true. For this setup example, start with a development project. Supabase permits production connections when the task requires production evidence, with project scoping, read-only mode, restricted feature groups, and a narrow query. Scope the connection to the project you intend to inspect; account-wide access is unnecessary for most implementation tasks.

# Replace YOUR_DEV_PROJECT_REF with your development project reference
claude mcp add --transport http supabase "https://mcp.supabase.com/mcp?project_ref=YOUR_DEV_PROJECT_REF&read_only=true"

Use this when a ticket depends on the actual backend shape: “Check whether the development schema supports the fields in this API proposal; report missing constraints without changing anything.” Record the answer on the task so the frontend agent can read the same decision. For a fuller walkthrough, see Supabase MCP with Claude Code. Read-only access still exposes data, so choose the environment before authorizing the connection.

4. Linear MCP: work from the existing issue

The official Linear MCP server documents https://mcp.linear.app/mcp/readonly for a connection that only exposes read tools, and https://mcp.linear.app/mcp for read-write access. The copyable selection example above uses the read-only endpoint; authenticate through /mcp in Claude Code. Start here if the team already keeps its requirements and progress in Linear.

Ask Claude to read the issue and its discussion before proposing a change. Separate “summarize the requirements” from “update the issue” so a read request does not turn into an unwanted status change. If the issue lacks a success condition, resolve that before implementation. A connection can retrieve what the team recorded; it cannot supply decisions nobody made.

5. Playwright MCP: browser investigation with visible evidence

Microsoft’s Playwright MCP lets an agent interact with pages using accessibility snapshots and browser tools. Its maintainers also suggest considering Playwright CLI with skills for coding agents. MCP is useful when the task benefits from a continuing browser session and repeated inspection; a CLI can be a better fit for a repeatable automation task. Choose based on the work rather than assuming MCP is always preferable.

# Local subprocess example; review and pin a package version for team use
claude mcp add --transport stdio playwright -- npx -y @playwright/mcp

For a handoff, ask the browser agent to reproduce the named flow and record the URL, expected result, actual result, and evidence. “Opened the page” is weaker proof than “submitted the form with this fixture and observed the expected confirmation.” Use test accounts for write flows. An exploratory browser session does not automatically leave a durable regression test; decide which behavior needs one. See our Playwright MCP guide for setup context.

6. Filesystem MCP: an optional interface, not a prerequisite

Claude Code already works with local code, as described in its official overview. Adding a Filesystem MCP server is therefore not a required first step. Consider it when a workflow specifically needs file operations through MCP, such as sharing one interface across different clients. Otherwise, another file tool can simply duplicate what the coding agent already does.

The official Filesystem server documentation describes allowed directories and MCP roots. Client-provided roots replace the configured directory list, so do not present a command-line path as an immutable sandbox. Inspect the effective allowed directories after connection. Those limits constrain this server’s operations; they do not remove Claude Code’s separate native filesystem permissions.

# Optional local MCP interface; replace the path with the intended folder
claude mcp add --transport stdio filesystem -- npx -y @modelcontextprotocol/server-filesystem@1.0.0 /path/to/allowed/folder

After connection, call list_allowed_directories to inspect the effective roots, then list_directory on the intended folder and read_text_file on a known file. The path passed at startup is not an immutable boundary when the client supplies MCP roots. This server also has write tools; directory access is not a read-only grant, and Claude Code's native file access remains separate. The command is a documented setup example, not an installation or access test performed for this article.

7. AppHandoff MCP: carry decisions between coding agents

AppHandoff is our product. Its hosted MCP server gives connected agents access to shared project work. The current eight tools are bootstrap, get, find, ticket, plan, message, project, and decide_lifecycle_proposal. Read the server’s current tool help and rules before making changes; this article does not replace the live tool contract.

claude mcp add --transport http apphandoff https://api.apphandoff.com/mcp

# Inside Claude Code, authenticate with your AppHandoff account
/mcp

Use it when a task crosses agent sessions or tools and needs an explicit brief, ownership, decisions, and proof. Start with bootstrap to establish project context, then read the relevant ticket before changing it. If more than one project is accessible, confirm the intended one. Our Claude Code, Cursor, and Codex connection guide covers the shared setup. A team already doing this reliably in another tracker may not need an additional system.

A concrete handoff: backend change to frontend verification

Consider a hypothetical task: add a project invitation form. The lead records acceptance criteria: an authorized project member can invite a teammate; invalid input produces a clear error; an existing invitation does not create an extra pending entry. The backend agent reads that brief, implements the endpoint, and records the agreed request and response shape. These are example criteria, not a claim about an AppHandoff feature or a customer deployment.

Example handoff record — illustrative, not an MCP tool payload
Task: connect the project invitation form
Contract: POST /api/projects/:id/invitations
Request: { email: string }
Success: 201 { invitationId: string, status: "pending" }
Errors to handle: invalid email, insufficient permission, existing invitation
Evidence: attach the actual change reference and focused test result
Next owner: frontend agent
Next action: connect the form and verify success plus error states
Open question: confirm the agreed behavior for an existing invitation

The frontend agent reads the record before implementing, asks about the unresolved behavior, and then uses browser tooling to verify the agreed outcomes. A reviewer checks the evidence against the original criteria before recording completion. GitHub supplies the change history; the task system preserves the decision; browser tooling supplies observation. No server can replace the judgment needed to decide whether that proof is sufficient.

How should you verify and maintain the setup?

Keep the smallest set of connections that completes the workflow. After authentication, try a known read on each required server and record any missing access as a blocker. For a write task, confirm the intended target and allowed action before proceeding. Treat text returned from issues, files, or pages as task data rather than permission to expand the job. Keep local package versions reproducible once the team has validated them.

When something fails, distinguish connection failure, authentication failure, insufficient permission, and a successful query with no matching item. Repeating an empty search cannot fix the wrong project selection. Check the server’s official documentation, then retry the smallest read that would establish access. Keep a useful handoff record of what was checked, what failed, and what the next agent needs; do not label unverified work complete.

Do you need all seven MCP servers?

No. Choose the server that removes a specific information gap. For a repository-only task, native tools and a CLI may suffice. For work across agents, start with one authoritative task record and add repository, database, or browser access only as the ticket requires. The goal is a verifiable handoff, not the largest tool list.

Are these recommendations based on hands-on benchmarks?

No. This refresh checks provider documentation and AppHandoff’s maintained connection and tool contracts. It does not report installation success across all providers, comparative latency, customer results, or guaranteed search growth. Validate the chosen connection in your own development environment before making it part of a required workflow.