MCP Servers Overview

What it integrates#

The Model Context Protocol (MCP) is an open protocol for exposing tools, resources, and prompts from an external server to a language-model client. Claude Code is one such client. Once an MCP server is connected, the tools that server exposes appear alongside Claude Code’s built-ins, callable in the same conversation loop.

What you can connect via MCP:

• First-party app integrations — Slack, Gmail, Google Drive, Google Calendar, Sentry, BigQuery, Atlassian (Jira/Confluence), Amplitude, Zoom. These let Claude Code read and act against your work tools.
• Custom internal servers — any system you can wrap in an MCP server. Your service’s API, your internal database, your build system, your incident tracker.
• Community servers — third-party MCP servers for Postgres, SQLite, Puppeteer-style browser automation, GitHub (alternative to gh), filesystem access, and many more.

What MCP is not: a remote-execution platform for arbitrary code, or an authentication system. It’s a protocol for tool/resource exposure; the auth and the security boundary are the integrator’s job.

Setup#

Authenticating a first-party app MCP#

For Anthropic-shipped integrations (Slack, Gmail, Drive, Calendar, Sentry, BigQuery, Atlassian, Amplitude, Zoom), the flow is uniform:

1. Inside a Claude Code session, ask the model to use the integration (or invoke its auth tool directly: mcp__claude_ai_Slack__authenticate).
2. Claude Code returns a URL. Open it in a browser, complete the OAuth flow, copy the verification code back.
3. Call the integration’s complete_authentication tool with the code. The session now has access to the integration’s tool surface.

The OAuth grant is scoped — you authorise specific permissions (e.g. “read messages in selected channels”) and that’s all Claude Code can do via the integration. Revocation lives in the upstream provider’s settings, not in Claude Code.

Adding a custom or community MCP server#

A custom server is added by editing the MCP configuration in your user-level Claude Code settings or in ~/.claude/mcp.json (paths and format may evolve — check the current docs). A minimal entry:

{
  "servers": {
    "my-postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost/mydb"]
    }
  }
}

Local servers run as a subprocess of Claude Code, speaking JSON-RPC over stdio. Remote servers run somewhere else and Claude Code connects over HTTP/SSE (Server-Sent Events). The configuration tells Claude Code which transport to use and how to start (or reach) the server.

Restart and discovery#

After editing MCP config, restart the Claude Code session. On startup the client connects to each configured server, asks “what tools, resources, and prompts do you expose?” via the protocol’s discovery methods, and registers them. The new tools then appear in the session — prefixed with the server name so they don’t collide with built-ins or with each other.

Capabilities#

MCP servers expose three primitives:

• Tools — callable functions with a JSON-schema-typed input. The model can invoke these the same way it invokes built-ins. Examples: slack__send_message(channel, text), bigquery__run_query(sql), github__create_issue(owner, repo, title, body).
• Resources — readable URIs the model can fetch. Each resource has a URI and a MIME type. Examples: a Notion page, a file in cloud storage, a row in a database. Used when the model wants reference data without invoking an action.
• Prompts — pre-canned prompt templates the server publishes. Less commonly used; lets a server suggest “if the user wants to triage a Sentry issue, here’s a structured prompt that works well.” Showed up as a primitive in early MCP design; adoption in practice is lighter than tools and resources.

A single server can expose any combination of the three. The Slack server, for example, exposes tools (send message, search messages) and resources (a specific message URI you can read). The protocol leaves it to the server author to decide which primitive best fits each capability.

Configuration#

The three knobs that matter most#

1. Which servers are enabled. Adding a server adds its tools to every session that loads this config. Removing it the only way to revoke at the client side. Be selective.
2. Auth scope. For OAuth-based servers (most first-party integrations), the granted scopes determine the blast radius. Read-only access is much safer than read-write; channel-scoped is much safer than workspace-wide.
3. Transport. Local (stdio subprocess) keeps the data on your machine; remote (HTTP/SSE) sends it across the network. Local is the default for custom servers; remote is the default for hosted/managed servers.

Per-server isolation#

Each MCP server runs in its own process (for local) or its own network endpoint (for remote). Crashes are isolated; a buggy server doesn’t take down others. Auth is per-server too — re-authenticating Slack doesn’t affect Drive.

Telemetry and audit#

MCP tool calls flow through the same audit surface as built-in tool calls: PreToolUse and PostToolUse hooks fire on every invocation. If you want to log every Slack message Claude Code sends, the right place is a PostToolUse hook matching the Slack server’s send-message tool, not anything inside the server itself.

Failure modes#

The recurring ways MCP integrations break in practice:

• Auth expiry. OAuth tokens rotate. A Drive integration that worked yesterday returns 401s today because the refresh-token flow needs re-doing. The fix is usually re-authentication, but the symptom often looks like a server bug at first.
• Schema drift. The server updates a tool’s input shape; the model has a cached idea of the old shape; calls start failing validation. Restart the session to re-discover the schema.
• Network flakiness on remote servers. Remote MCP servers add a network hop. Timeouts and partial responses become possible in ways they aren’t for built-in tools. The session feels slow or hangs intermittently.
• Rate limits. Upstream APIs throttle. A Slack workspace with aggressive rate limits will rate-limit Claude Code’s sends just like it rate-limits any other client. The tool call surfaces the upstream error.
• Discovery failures. A configured server fails to start (bad command, missing dependency, wrong port). The session opens without that server’s tools and continues; you may not notice until you ask for something that needed those tools. Check session-startup logs.
• Tool name collisions. Two servers expose tools with similar names. The model picks the wrong one. Disambiguate by enabling only the server you need for the session, or by using more specific tool names in custom servers you author.

Security and permissions#

The trust boundary with MCP is on the integrator, not the protocol. Three things to decide before turning a server on:

1. What can it read? Whatever data it reads will flow into Claude Code’s context window. For Drive, that’s potentially every doc you own; for Postgres, every row you query. Scope reads tightly.
2. What can it write? Tools that send messages, create issues, modify rows, deploy code — these are actions in the world. They cannot be undone by a redirect in the next turn. Use permission rules to require confirmation on consequential write tools.
3. Where does the data go? Local servers keep data on your machine; remote servers ship it to the server’s hosting environment. The privacy contract is whatever the server author publishes — read it.

For first-party Anthropic-shipped MCPs, the auth scopes and data-handling are documented per-integration. For community and custom servers, you own that diligence.

A practical heuristic: read-only servers are fine to default-on; write-capable servers should require explicit per-tool permission rules. A PreToolUse hook that prompts on every Slack send is annoying for one session; cheaper than the cost of one accidentally-sent message.

Related integrations#

• Building an MCP Server
• App MCPs — Slack, Gmail, Drive, Calendar
• GitHub Integration
• VS Code Extension