Anthropic adds remote MCP support to Claude Code

Source record: remote MCP support in Claude Code

On June 18, 2025, Anthropic announced remote Model Context Protocol support in Claude Code. The announcement said Claude Code could connect to tools and resources exposed by remote MCP servers, with examples involving development tools, project-management systems, and knowledge bases. It described adding a vendor URL to Claude Code rather than operating a local server, and it described native OAuth support for remote server connections.

The announcement also placed responsibility for updates, scaling, and availability with the remote-server vendor. That is a useful architectural fact. Remote connection reduces local server management, while the connected system remains a separate service with its own identity model, capability set, availability behavior, and change history. A useful integration review starts by identifying those boundaries before an agent receives access to the new tools.

A server connection is a capability contract

MCP makes tools and resources discoverable, but a client still needs a local policy for their use. List every exposed tool, input schema, output type, data classification, action effect, owner, and approval requirement. A narrow connection such as issue lookup can have different risk from a connection that changes a ticket, edits a record, or publishes a release. Treat each operation as a separately reviewable capability rather than grouping them under one broad server label.

OAuth establishes an authenticated connection; the application still chooses scopes, session lifetime, revocation behavior, and how an agent request maps to a user or service identity. Record the server endpoint, configuration version, approved scopes, and the actual tools enabled for a workspace. This gives a team a durable way to understand what changed when a server adds a new operation or a configuration review alters the available surface.

Hypothetical example: issue context for a code review

Consider a hypothetical code-review workflow with a remote issue-tracker server. The workflow receives a pull request identifier and may call one read-only tool to fetch the linked issue title, acceptance checks, and approved labels. It passes those fields into a review prompt alongside the source diff. The output is a draft review that cites the issue identifier and the revision it analyzed. The connection has no tool for changing issue state or adding comments.

When the issue server returns an access error or an issue that does not match the repository, the workflow records the mismatch and completes without issue context. A reviewer can correct the link or proceed with a source-only review. The bounded design keeps the remote connection useful while making its contribution visible. It also prevents a missing or unexpected external response from becoming an instruction to expand access during the same task.

Architecture: bind identity, scope, and action

Store remote-server configuration as reviewed application state. The configuration should name the endpoint, transport, allowed tools, allowed resources, authentication method, scope set, timeout, and owner. Resolve server metadata before enabling it for a workflow, then compare the discovered tool catalog with the reviewed allowlist. A new tool name, changed schema, or broadened resource pattern should produce a configuration review rather than silently changing an agent's operating surface.

For consequential tools, separate proposal from execution. A model can prepare a structured action request containing the target, parameters, source evidence, and reason. A policy layer validates that request against the server's allowed operations and the caller's permissions. The receiving system confirms the result and returns a receipt. This pattern creates a clear chain from context retrieval through authorized action without relying on an informal conversational instruction.

Failure modes: server changes and confused authority

Remote servers can change their tool catalogs, return incomplete resources, redirect a request, or experience an outage. An agent can also confuse a retrieved instruction with a trusted policy, especially when external content contains imperative language. Protect the workflow by treating returned text as data, validating tool arguments against schemas, and applying the same action policy after a tool response as before it. The remote endpoint is an input boundary, not a policy authority.

Test expired authorization, revoked access, added tools, changed schemas, malformed responses, response delays, and an external resource that asks the agent to take an unrelated action. Verify that the workflow surfaces the error category, preserves the task identity, and leaves any state-changing step pending for review. These tests make the operational behavior of a remote connection visible before a team relies on it in a larger workflow.

Evaluation checklist: review the integration as software

Build fixtures for the server's expected resources and tool responses, including permission failures and changed fields. Evaluate whether the agent calls only the approved operations, produces traceable use of returned information, and respects the task scope when the external system is unavailable. Review the OAuth scopes, account ownership, logging policy, and revocation procedure with the team responsible for the connected service. Keep a record of each enabled server and why it is enabled.

A rollout can begin with a read-only server, a limited workspace, and clear telemetry for connection failures and tool invocations. Add consequential tools only after the receiving system, authorization path, retry behavior, and receipt format have been tested. Re-run the review when the server catalog, authentication configuration, or workflow changes. That turns a convenient remote connection into an engineering dependency with known boundaries and accountable ownership.

Related capabilities

• MCP integration and interoperability