MCP and Claude agents

MCP is now a Linux Foundation project. What it is, how Claude uses it across desktop, Claude Code and the API, how to configure a server, and which integrations exist today.

The Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems - files, databases, SaaS tools and internal APIs - through one uniform interface. Claude speaks MCP in three places: the desktop and web apps (as “connectors”), Claude Code, and the Claude API's MCP connector beta. Since 9 December 2025 the protocol is not Anthropic's to control: it belongs to the Linux Foundation.

This page explains what MCP actually does, who governs it now, how to configure a server for each Claude surface, which integrations are documented today, and - the part most guides skip - what an MCP server can do to you if you scope it badly.

#What is MCP and what problem does it solve?

Before MCP, every pairing of an AI application and an external system was a bespoke integration. Ten apps and ten tools meant a hundred connectors, each with its own auth handling, its own schema conventions and its own maintainer. MCP replaces that with a client/server split: the MCP server wraps a system and publishes what it can do; the MCP client - Claude, in this case - discovers those capabilities at connect time and calls them. The protocol's own documentation uses the analogy of a USB-C port for AI applications, which is the right level of ambition: a shape, not a product.

A server exposes three kinds of thing. Tools are functions the model can invoke - create_issue, run_query, send_invoice. Resources are readable content the client can pull in, like a file or a record. Prompts are reusable templates the server offers the user. In practice tools dominate, and on the Claude API tools are the only part supported - more on that below.

The practical payoff is that a server written once works everywhere. The same Sentry or Notion server that runs behind the Claude chat app also plugs into Claude Code, into VS Code, into Cursor, and into competing assistants. That portability is the reason the ecosystem grew fast enough to need a neutral home.

#Who controls MCP now that it is a Linux Foundation project?

Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation (AAIF) on 9 December 2025. The AAIF was co-founded by Anthropic, Block and OpenAI, with backing from Google, Microsoft, AWS, Cloudflare and Bloomberg. MCP joined two sibling founding projects: Block's goose agent framework and OpenAI's AGENTS.md convention.

This matters for planning, not just for trivia. It means MCP is no longer a vendor extension you adopt at the risk of a single company's roadmap - the same argument that used to favour building on a raw HTTP API now cuts the other way. Anthropic stated that the governance model itself is unchanged and that maintainers continue to prioritise community input and transparent decision-making, so day-to-day the spec still moves the way it did. But the licence to the protocol, and the ability to steer it, are now shared.

#Where does Claude actually use MCP?

Three surfaces, three different levels of capability. Choosing the wrong one is the most common reason an MCP project stalls.

The apps are the right place for personal and knowledge-work use - a connector you authorise once and forget about. Claude Code is the right place when the server needs to touch your machine, because it is the only surface that can launch a local stdio server. The API connector is for putting MCP tools inside your own product, and it is the most constrained of the three.

#Configuring a server for Claude Code

Claude Code takes servers from the command line and stores them at one of three scopes: local (just you, just this project - the default), project (written to .mcp.json and committed, so the whole team gets it), and user (you, everywhere).

# A remote HTTP server, shared with the team
claude mcp add --transport http --scope project sentry https://mcp.sentry.dev/mcp

# A remote SSE server
claude mcp add --transport sse asana https://mcp.asana.com/sse

# A local stdio server, launched as a subprocess
claude mcp add airtable --env AIRTABLE_API_KEY=key... -- npx -y airtable-mcp-server

# Check what is connected and healthy
claude mcp list
claude mcp get sentry

The project scope writes a file you can read, diff and review - which is the reason to prefer it. A minimal .mcp.json looks like this:

{
  "mcpServers": {
    "sentry": {
      "type": "http",
      "url": "https://mcp.sentry.dev/mcp"
    },
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer ${GITHUB_TOKEN}"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@bytebase/dbhub", "--dsn", "${DATABASE_URL}"]
    }
  }
}

Two details that catch people out. First, "type": "streamable-http" is accepted as an alias for "http", so both spellings work. Second, a handful of server names are reserved and will be rejected: workspace, computer-use, claude-in-chrome, Claude Preview and Claude Browser. Inside a session, /mcp shows connection status and lets you complete OAuth flows for servers that need them.

#Calling MCP servers from the API

On the Claude API, MCP arrives as a beta feature behind the header mcp-client-2025-11-20. You declare the servers, then declare a matching mcp_toolset entry in tools - every server must be referenced by exactly one toolset, or the request fails.

import anthropic

client = anthropic.Anthropic()

message = client.beta.messages.create(
    betas=["mcp-client-2025-11-20"],
    model="claude-sonnet-5",
    max_tokens=4096,
    mcp_servers=[
        {
            "type": "url",
            "url": "https://mcp.sentry.dev/mcp",
            "name": "sentry",
            "authorization_token": SENTRY_TOKEN,
        }
    ],
    tools=[
        {
            "type": "mcp_toolset",
            "mcp_server_name": "sentry",
            "default_config": {"enabled": False},
            "configs": {
                "list_issues": {"enabled": True},
                "get_issue_details": {"enabled": True},
            },
        }
    ],
    messages=[
        {"role": "user", "content": "Summarise the top 5 unresolved issues from the last 24 hours."}
    ],
)

That default_config / configs pair is the important part: it turns everything off by default and re-enables two named tools. Allowlisting is almost always what you want, because a server can add tools at any time and you do not want a model discovering a new delete_project the week its maintainer ships it. There is also a defer_loading flag that keeps a tool's definition out of context until it is needed, which matters once you are wiring in dozens of tools.

#Which MCP servers can you connect to Claude?

Anthropic's own Claude Code documentation names a specific set of servers with their endpoints. These are the ones to start from, because they are documented by the vendor rather than found in a list somewhere.

Beyond that documented set, Anthropic's public connectors directory lists over a hundred entries organised by use case, and the open MCP Registry lists many more. The tasks Anthropic itself documents give a fair sense of the shape of the work: implementing a feature from a Jira issue and opening a GitHub pull request, analysing Sentry and Statsig data together, querying a PostgreSQL database in plain language, updating an email template from a Figma design posted in Slack.

#MCP security: a server gets real access

An MCP server is not a plugin in the browser-extension sense. It is a piece of software holding a credential to a system you care about, invoked by a model that is reading untrusted text. Three failure modes are worth naming explicitly.

Practical rules that hold up: give each server the narrowest credential that still does the job; separate read servers from write servers where the vendor allows it; allowlist tools rather than denylisting them; keep the server list in .mcp.json under code review like any other dependency; and on Team and Enterprise plans, use per-tool connector controls so administrators can permit reads while disabling writes across the organisation. Anthropic's own guidance on letting Claude act directly on live systems is notably unenthusiastic - it describes the risk as real despite safety classifiers - and that framing is the right one to adopt.

#Which model should run an MCP agent?

Tool-calling reliability, not raw intelligence, is what determines whether an MCP agent works. Anthropic positions Opus 5 as the default for complex agentic work, and Fable 5 above it for long-running agents where a failure costs more than the tokens. For most MCP workloads Sonnet 5 is the sensible starting point, and Haiku 4.5 handles high-volume routing and classification steps at a fifth of Opus 5's input price.

One cost note specific to tools: every tool definition sits in your input context on every turn. A server with sixty tools is a standing token bill. Use defer_loading, prune the allowlist, and cache the system prompt - the mechanics are worked through on the automation page. If you would rather build the same integrations visually than in code, Claude agents in n8n covers the node-based route, including n8n's own MCP client and server nodes. For a broader tour of the developer surfaces, start at Claude for developers.

#Frequently asked questions