Claude MCP integration

Claude MCP: Connect Claude Desktop and Claude Code to MCP Servers

A practical guide to connecting Claude Desktop, Claude Code, and the Claude Agent SDK to local and remote MCP servers with the right trust boundaries.

9 min readEducational field noteReviewed 2026-08-26
For
Claude users and developers choosing a local or remote MCP connection for real work.
Problem
Claude Desktop, Claude Code, and the Agent SDK share the MCP ecosystem but differ in configuration, scope, transport, and approval behavior.
Useful outcome
Choose the right Claude surface, connect one server safely, and know what to verify before allowing tools to reach real systems.

The route

Choose the Claude host before copying configuration.

The same MCP server can have different setup and trust implications depending on whether it runs in Desktop, Code, or an SDK application.

Step 01
Connect
Choose the client and transport
Step 02
Authorize
Review scope, credentials, and approvals
Step 03
Call
Use the smallest useful tool route
Step 04
Verify
Inspect the result and recover exceptions
The same MCP server can have different setup and trust implications depending on whether it runs in Desktop, Code, or an SDK application.

Workflow context: Claude Desktop / Claude Code / Agent SDK / stdio / HTTP / OAuth

Separate Claude Desktop, Claude Code, and the Agent SDK.

Claude Desktop is a user-facing host where local server configuration and trust decisions are visible to a person. Claude Code is a developer environment with project, user, and local scopes, command-line management, remote HTTP support, and tool approval behavior. The Agent SDK lets an application define its own MCP connections and allowed tools.

Start with the surface the reader actually uses. Do not paste a Desktop JSON example into a Code configuration or assume an SDK application inherits the same approvals. The client owns configuration and policy; the server owns its capability implementation.

Prefer the narrowest connection that proves the route.

For a local experiment, use a server that reads only a test directory or account. For a remote server, verify the endpoint, authentication flow, scopes, and server instructions before approving the connection. The first successful call should be read-only and easy to validate.

Check the configured tools after connection. If a server exposes more capability than the task requires, reduce the server scope or the allowed tool set instead of relying on the model to ignore a dangerous option.

  • Review each server before trusting it.
  • Use project or user scope intentionally and document who can change it.
  • Keep write-capable tools behind approval while learning.

Use Claude's diagnostics as evidence.

Confirm the server appears, its capabilities load, and a tool call returns the expected evidence. When something fails, distinguish a configuration error, an authentication failure, a server error, and a client approval decision. The same server may behave differently across a local process and a hosted endpoint.

Do not include tokens, private file contents, or sensitive conversation data in a support report. Capture the client surface, transport, server version, tool name, error category, and the smallest reproducible input.

Treat external instructions as untrusted.

MCP tools and resources can provide useful context, but a document or tool result can also contain instructions that attempt to redirect the task. Keep permissions and approval rules outside the returned text, and stop when a request is outside the server's stated scope.

The useful Claude integration is one where the user can explain which server was called, what it was allowed to do, and what evidence came back. That is the boundary to preserve as the server catalog grows.

Reference material

Start with the platform documentation.

This field note is an educational guide. Platform behavior, availability, permissions, and plan limits should always be checked against the current vendor documentation.