---
title: "Connecting MCP servers to Claude, ChatGPT, IDEs and agents"
description: "The host landscape (September 2026) MCP support is now broad, but features differ by host (tools only, or also resources, prompts, elicitation, MCP Apps…"
url: https://optimizeall.com/learn/model-context-protocol-mcp/connecting-servers-to-ai-hosts
updated: 2026-10-05
---

Model Context Protocol (MCP): Connect AI to Your Tools and Data · Connecting hosts and building clients · lesson 9 of 18 · 15 min

# Connecting MCP servers to Claude, ChatGPT, IDEs and agents

## The host landscape (September 2026)

MCP support is now broad, but **features differ by host** (tools only, or also resources, prompts, elicitation, MCP Apps; local stdio, remote HTTP, or both; OAuth support; admin controls). Always check the host's current documentation. Commonly used MCP hosts include:

| Host | Typical connection | Notes |
|---|---|---|
| **Claude Desktop** | Local stdio servers via `claude_desktop_config.json`; remote servers as connectors | Also supports desktop extensions packaging local servers |
| **Claude (web/mobile)** | Remote servers added as **custom connectors** (Streamable HTTP + OAuth) | Org admins can manage connectors on team/enterprise plans |
| **Claude Code** | `claude mcp add` (stdio or HTTP), project-scoped `.mcp.json` | `/mcp` in a session lists servers and tools |
| **ChatGPT** | Remote MCP servers in apps/connectors (developer mode for custom servers) | Check plan availability and current naming |
| **VS Code (GitHub Copilot agent mode)** | `.vscode/mcp.json` with a `servers` key and `type` per entry | Requires agent mode for tool calls |
| **Cursor** | `.cursor/mcp.json` with `mcpServers` | |
| **Agent SDKs and APIs** | Claude API MCP connector, OpenAI Responses remote MCP tool, OpenAI Agents SDK, Google ADK, LangGraph adapters, Claude Agent SDK | Programmatic, in your own apps |

## Local server configuration (stdio)

Most desktop/IDE hosts use the same idea: a **command** plus **args** (and optional **env**). Examples:

```json
{
  "mcpServers": {
    "campaign-analytics": {
      "command": "/absolute/path/to/uv",
      "args": ["run", "--with", "mcp[cli]", "mcp", "run", "/absolute/path/to/server.py"],
      "env": {"ANALYTICS_DSN": "postgresql://readonly@db.internal/analytics"}
    }
  }
}
```

That shape works for Claude Desktop (`claude_desktop_config.json`) and Cursor (`.cursor/mcp.json`). VS Code uses `"servers"` and adds `"type": "stdio"`. Claude Code needs no file:

```bash
claude mcp add campaign-analytics -- uv run --with "mcp[cli]" mcp run /absolute/path/to/server.py
```

Tips: use absolute paths (hosts start servers from their own working directory), restart the host after editing config (fully quit Claude Desktop), and keep secrets out of files committed to git: reference environment variables or a secret manager.

## Remote servers

Remote servers are added by **URL** (for example `https://mcp.example.com/mcp`). The host discovers the authorization server via Protected Resource Metadata, runs an OAuth flow in the browser, and stores tokens. For Claude Code: `claude mcp add --transport http crm https://mcp.example.com/mcp`. Custom connectors in Claude and ChatGPT use the same URL-based approach through their settings UI. Only add remote servers from organizations you trust; the server sees every argument the model sends it.

## Using MCP from your own code

**Claude API MCP connector** (beta at the time of writing): Claude connects to a remote server directly from the Messages API.

```python
import os
import anthropic

client = anthropic.Anthropic()
resp = client.beta.messages.create(
    model=os.environ.get("MODEL", "claude-sonnet-5"),
    max_tokens=4000,
    betas=["mcp-client-2025-11-20"],                  # check current beta name in the docs
    mcp_servers=[{"type": "url", "url": "https://mcp.example.com/mcp", "name": "crm",
                  "authorization_token": os.environ["CRM_MCP_TOKEN"]}],
    tools=[{"type": "mcp_toolset", "mcp_server_name": "crm"}],
    messages=[{"role": "user", "content": "Which deals over £10k are stuck in proposal?"}],
)
print("".join(b.text for b in resp.content if b.type == "text"))
```

**OpenAI Responses API** has a remote MCP tool type (`{"type": "mcp", "server_label": ..., "server_url": ..., "require_approval": ...}`) and the **OpenAI Agents SDK** offers `MCPServerStdio` and `MCPServerStreamableHttp` with approval policies. **Google ADK**, **LangGraph** (via adapters) and the **Claude Agent SDK** (`mcp_servers` in options) also consume MCP servers. For local servers, prompts or resources, or full control, write your own client (next lesson).

## Governance in hosts

- Prefer **org-managed** connector lists over individuals adding arbitrary servers.
- Review each server's tools and scopes before enabling; enable only needed toolsets.
- Keep "always allow" permissions for read-only tools; require confirmation for writes.
- Periodically re-review: servers can change tool definitions.

## Worked example: rolling one server out to three hosts

A Manchester agency deploys its remote `crm` server (Streamable HTTP + OAuth via Microsoft Entra ID):

- **Claude (Team plan)**: admin adds it as an org connector; account managers authenticate once.
- **VS Code (developers)**: `.vscode/mcp.json` in the internal tools repo points to the URL.
- **Reporting agent**: uses the Claude API MCP connector with a service token scoped to read-only tools.

One server, one audit log, three very different clients. When they renamed a tool, they announced it in a changelog and tested all three hosts first.

## Hands-on: connect and verify

1. Connect your server from module 3 to two hosts (for example Claude Desktop or Claude Code, plus VS Code or Cursor).
2. In each, confirm the tool list, run the same three prompts, and note differences (does the host show resources? prompts? confirmation dialogs?).
3. Record which features each host supported.

## Pitfalls

- Relative paths in config; the server silently fails to start.
- Committing tokens in `mcp.json` files.
- Assuming every host supports prompts, resources or elicitation.
- Letting users connect unknown remote servers to accounts holding sensitive data.

## Measuring success

Time for a new user to connect, success rate of first tool call, per-host feature coverage, and number of unmanaged servers in your organization (aim to drive it down).

## Video lecture: Connecting MCP servers to Claude, ChatGPT, IDEs and agents

Lecture coming soon · 15 chapters · about 9 minutes. Read the full transcript below.

1. Connecting to hosts
2. Why connecting matters
3. The host landscape
4. Local (stdio) setup
5. Remote setup
6. Simple example: two hosts, two minutes
7. MCP from your code
8. Governance
9. Example: one server, three hosts
10. Hands-on: two hosts, three prompts
11. Desktop and web hosts
12. Deeper: the Manchester rollout (illustrative)
13. Watch me do it: three connections
14. Try this now
15. Recap

## Lecture transcript

### Connecting to hosts

You've built a server. Now it needs to meet its users, inside Claude, ChatGPT, code editors and your own agents. In this lesson you'll learn how each kind of host connects to MCP servers, how local and remote configuration differ, how to call MCP from your own code, and how to govern it all.

### Why connecting matters

Why does connecting deserve its own lesson? Because this is where most people first give up. The server works in a terminal, but the host shows nothing, or an error with no detail. The concepts are simple, but each host has its own configuration style and feature set. Think of traveling with electronics. The device is the same everywhere, but every country has a different plug. Once you know the plug types, it's routine. Until then, it's frustrating.

### The host landscape

MCP support is now broad, but uneven. Some hosts only use tools. Others also show resources, prompts, elicitation forms or interactive MCP Apps. Some run local servers, some only remote ones, some both. Claude Desktop runs local servers from a config file and remote ones as connectors. Claude on the web adds remote servers as custom connectors. Claude Code uses a single command. ChatGPT supports remote servers through its apps and connectors. And VS Code with Copilot's agent mode and Cursor use small JSON files. Always check each host's current docs.

### Local (stdio) setup

Local servers are configured the same way almost everywhere: a command, its arguments, and optional environment variables. Claude Desktop and Cursor use an mcp servers key. VS Code uses a servers key and adds a type for each entry. Claude Code skips the file entirely: claude mcp add, a name, then the launch command. Three tips save hours. Use absolute paths, because hosts start servers from their own folder. Fully restart the host after editing config. And never commit tokens in these files; reference environment variables or a secret manager.

### Remote setup

Remote servers are added by URL, like https colon slash slash mcp dot example dot com slash mcp. The host discovers the authorization server from the server's metadata, runs an OAuth sign in in your browser, and stores the tokens. In Claude Code, you pass transport http and the URL. In Claude and ChatGPT, you add a custom connector in settings. And only connect remote servers from organizations you trust, because the server sees every argument the model sends it.

### Simple example: two hosts, two minutes

A simple example. Your stdio server is at a path in your home folder. In Claude Code you run claude mcp add with the name and the absolute launch command, then type slash mcp to confirm it's connected. In VS Code you create a small JSON file in your project with a servers key, a stdio type, the command and its arguments, then confirm it's running from the command palette. Two hosts, two minutes each, and you can now compare how each one presents the same tools.

### MCP from your code

You can also use MCP from your own code. The Claude API's MCP connector, in beta at the time of writing, lets Claude call a remote server directly from a messages request: you list the server with its URL and token, and add an MCP toolset that references it. OpenAI's Responses API has a remote MCP tool type, and the OpenAI Agents SDK offers standard I O and Streamable HTTP server classes with approval policies. Google's ADK, LangGraph adapters and the Claude Agent SDK can consume MCP servers too.

### Governance

Governance matters as soon as more than one person is involved. Prefer an organization managed list of connectors over individuals adding whatever they find. Review each server's tools and scopes before enabling it, and switch on only the toolsets a team needs. Keep always allow permissions for read only tools, and require confirmation for writes. And re review periodically, because servers can change their tool definitions.

### Example: one server, three hosts

A worked example. A Manchester agency runs one remote CRM server with OAuth through Microsoft Entra ID. In Claude, an admin adds it as an organization connector and account managers sign in once. Developers use it from VS Code via a small JSON file. And the reporting agent uses the Claude API connector with a service token limited to read only tools. One server, one audit log, three very different clients. When they renamed a tool, they announced it in a changelog and tested all three hosts first.

### Hands-on: two hosts, three prompts

Now your turn. Connect your server from module three to two hosts, for example Claude Code and VS Code. In each, confirm the tool list, run the same three prompts, and note the differences. Does the host show resources? Prompts? Confirmation dialogs? Record what each host supports. And avoid the classic mistakes: relative paths, tokens committed in config files, assuming every host supports every feature, and letting people connect unknown remote servers to accounts with sensitive data.

### Desktop and web hosts

A common question: can I use the same server from both a desktop host and a web host? Yes, if you offer the right transport for each. Desktop hosts can launch your server locally over standard I O, while web hosts like Claude on the web or ChatGPT need a remote URL. Many teams ship both: a local package for developers and a hosted remote endpoint for everyone else, built from the same code and tool definitions.

### Deeper: the Manchester rollout (illustrative)

Let's deepen the Manchester agency's rollout. The admin added the CRM server to Claude as an organization connector with read tools enabled for everyone and write tools only for account leads. In week one, illustrative numbers, most account managers connected within a day. Developers used it in VS Code to check client data while building reports. The reporting agent used a read only service token through the API connector. When a developer accidentally committed a VS Code config file, the security scan passed because it contained only the URL, no token: OAuth tokens stayed in each person's editor. One server, three hosts, and no secrets in any repository.

### Watch me do it: three connections

Watch me do it. Let's connect the same server to three places. First, Claude Code: I type claude mcp add, the name campaign analytics, two dashes, then the full launch command with absolute paths. Then slash mcp shows it connected with two tools. Second, VS Code: I create dot vscode slash mcp dot json with a servers key, an entry with type stdio, command uv and the arguments, and the command palette's list servers shows it running. Third, my own code with the Claude API MCP connector, for the remote version: messages create on the beta client, the MCP client beta flag, an mcp servers entry with type url, the URL, a name and a token from the environment, and a tools entry of type mcp toolset pointing to that name. I ask, which deals over ten thousand pounds are stuck in proposal, and the answer comes back using the server's tools.

### Try this now

Try this now. Connect one of your servers to two different hosts. In each, confirm the tool list, then run the same three prompts: a simple lookup, a multi step question, and something that should trigger a write or confirmation. Note what each host shows: resources, prompts, confirmation dialogs, error messages. Record it in a small table. That table will save your users hours, and it becomes part of your server's documentation.

### Recap

To recap: hosts differ, so verify features. Local servers need a command and absolute paths. Remote servers need a URL and OAuth. Your own apps can use connectors, SDKs or a custom client. And govern connectors centrally. Your next step: connect one server to two hosts, run three identical prompts, and document which MCP features each supported.

## Key takeaways

- MCP host support is broad but uneven; verify each host's supported features and transports.
- Local servers are configured as command plus args; remote servers by URL with OAuth.
- Use absolute paths, restart hosts after config changes, and keep secrets out of committed config.
- Your own apps can use MCP via the Claude API connector, OpenAI's remote MCP tool, agent SDKs or a custom client.
- Govern connectors centrally and require confirmation for write tools.

## Try it

Connect one server to two different hosts, run the same three prompts in each, and document which MCP features each host supported.

- [Previous: Designing MCP tools and servers that LLMs use well](https://optimizeall.com/learn/model-context-protocol-mcp/designing-mcp-tools-for-llms)
- [Next: Building MCP clients and wiring them into your own agent](https://optimizeall.com/learn/model-context-protocol-mcp/building-mcp-clients-and-agent-integration)
- [All lessons of Model Context Protocol (MCP): Connect AI to Your Tools and Data](https://optimizeall.com/learn/model-context-protocol-mcp)