How to connect Claude and ChatGPT to your own files, apps and data with MCP

MCP, the Model Context Protocol, is a standard way for an AI client to call tools that live outside it. A server exposes tools, such as read a file, run a query or search a mailbox. The client, Claude Desktop, Claude Code, claude.ai or ChatGPT, lists those tools and the model calls them. There are two kinds of server and they are set up in different places, which is where most confusion starts.

A local server is a program on our own computer. The client launches it and talks to it over standard input and output, which the docs call stdio. It goes in a config file, and it can reach anything on our machine, which is why we give it only the folders it needs. A remote server is a URL on the internet, usually ending in /mcp, speaking what the spec calls Streamable HTTP. It goes in as a custom connector, signs us in with OAuth, and never sees our disk.

Claude Desktop takes both. Claude Code takes both. claude.ai in the browser takes only remote. ChatGPT takes only remote, and only with developer mode on. If we remember just one thing, it is this: a URL never goes in the local config file, and a local command never goes in the connectors screen.

Most published local servers are run with npx (Node.js packages) or uvx (Python packages). Install Node.js from nodejs.org for the first and uv from astral.sh for the second. Then run the server once from a terminal before touching any config. If it does not start here, no client will start it either, and the terminal shows the error in plain text instead of a greyed-out menu.

The filesystem server from the MCP project is the right first server. It takes the folders it may touch as arguments and refuses everything else. Pick one folder we would be fine with a stranger reading. It starts, prints a line, and waits. That waiting is correct, it is listening for a client. Ctrl+C to stop it.

Note the full path of npx or uvx while we are here. Desktop apps on macOS and Windows do not always see the PATH that our terminal sees, and the full path is the fix in step 6.

Claude Desktop reads local servers from one file: claude_desktop_config.json. The way in is Claude menu, Settings..., Developer, Edit Config. That opens the folder with the file, and creates an empty one if it is missing. We can also go straight there.

On macOS the file is ~/Library/Application Support/Claude/claude_desktop_config.json. On Windows it is %APPDATA%\Claude\claude_desktop_config.json, which is C:\Users\you\AppData\Roaming\Claude once expanded. The Library and AppData folders are hidden by default, so paste the path into the Finder Go to Folder box or the Explorer address bar.

Open it in a real text editor, not TextEdit with smart quotes or Notepad with a hidden .txt suffix. Curly quotes are the most common reason a config refuses to parse, and the app does not tell us; it just shows no server.

If the Developer section is missing, update Claude Desktop first, older builds do not have it. If Edit Config opens an empty file, that is normal, we fill it in the next step. Once the file holds more than one server, copy it somewhere before each edit. The app does not back it up and does not warn when it cannot read it, so a bad edit silently removes every server at once, not just the new one.

The file is one JSON object with an mcpServers key. Each server is a name we choose, a command, and an args list where every argument is its own string. The name becomes the log filename, so keep it short and lowercase.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/Desktop"]
    }
  }
}

Rules that save an hour. Paths are absolute: /Users/you/Desktop, not ~/Desktop or ./docs, because the app does not expand them. On Windows every backslash is doubled inside JSON, C:\\Users\\you\\Desktop. No trailing commas and no comments, JSON allows neither. A second server is a second key inside mcpServers, not a second mcpServers. Secrets such as API keys go in an env object on the server, never in args, because args show up in the process list.

The generator below writes the JSON and, under it, the matching Claude Code one-liner from step 7. It cannot know whether we picked npx or uvx when it writes the -y flag, so with uvx delete that one argument. For the claude.ai connector option, read the comment it prints: local servers cannot be added there at all.

Claude Desktop reads the config once, at launch. Closing the window does not relaunch anything, the app is still running in the menu bar or the tray. Quit it from the Claude menu on macOS (or Cmd+Q), or from the tray icon on Windows, then open it again. This one rule explains about half of the "it does not show up" reports.

After the relaunch, the server appears in the tools list under the chat input and its tools can be turned on and off there. Ask something that needs it, plainly: list the files on my Desktop. The first call asks for permission to use the tool. Allow it for this chat, read what it did, then widen the permission if we are happy.

The logs are where we go when the list is empty. On macOS they are in ~/Library/Logs/Claude/: mcp.log for the app's view of all servers, and mcp-server-NAME.log for what each server printed. On Windows they are in %APPDATA%\Claude\logs. Open the server's own log first; a startup error is on the first few lines.

The failures are the same for everyone, and they come in a fixed order. We check them in that order and stop at the first one that applies. A full quit first, because it is free. Then the JSON, because a single curly quote or trailing comma makes the app ignore the whole file in silence. Then the kind of server, because a URL in the local config can never work. Then the server's own log.

The log tells us which of three things happened. ENOENT or a spawn error means the app could not find the command. On Windows this is nearly always because the app launched without the PATH or the APPDATA variable that npx needs, and the fix is to put the full path to npx.cmd in command and add an env object with APPDATA set to the expanded path, C:\\Users\\you\\AppData\\Roaming. On macOS, use the full path from which npx. A log that is missing or empty means the app never tried, so the problem is upstream: JSON or a path. A server that starts and then fails on the first call is usually a relative path or a folder it was not given.

For remote servers the question is different: can Anthropic's cloud reach the URL? A connector is contacted from Anthropic's servers, not from our laptop, so localhost, a LAN address or a VPN-only host will time out, and an OAuth flow that completes but returns 403 means the token is valid but the server is refusing that account.

Claude Code does not use claude_desktop_config.json. It has its own command that writes the right file for us, and it takes both kinds of server.

# a local stdio server
claude mcp add --transport stdio filesystem -- npx -y @modelcontextprotocol/server-filesystem /Users/you/Desktop

# a remote server, with a token if it needs one
claude mcp add --transport http docs https://host.example/mcp --header "Authorization: Bearer ..."

claude mcp list

The --scope flag decides who gets it. local is the default: this project, this machine, our user only, stored in ~/.claude.json. user is every project on this machine, also in ~/.claude.json. project writes a .mcp.json in the repo so the whole team gets the server when they pull; commit it, and keep secrets out of it by using headers that read environment variables or a server that does OAuth. Inside a session, /mcp lists the servers, shows which are connected, and runs the OAuth sign-in for a remote one. If a remote server needs a login, run /mcp before asking for anything that uses it.

Project scope is the one to be careful with in both directions. A .mcp.json we commit lets everyone who clones the repo launch that command on their machine, so Claude Code asks for approval before it uses a repo's project servers the first time. Read the file before saying yes to one in a repo we did not write, the same way we would read a script before running it.

A remote server is added from the connectors screen, and it is the same screen in the browser and in the desktop app. Customize, Connectors, + Add, Add custom connector. We give it a name, the URL (https://host/mcp, speaking Streamable HTTP), and an authentication choice: Sign in now, Sign in when needed, or No sign in. If the server hands out its own OAuth client, there is a field for that, and there is an optional request headers section for an API key. Then Add.

As of 28 October 2026 custom connectors are on every plan including Free, with Free limited to one custom connector. On Team and Enterprise plans only Owners can add them, so if the button is missing that is why. One quirk to know before we type: a connector cannot be edited. To change the URL or the auth, remove it and add it again.

Sign in when needed is the safe default. The first tool call opens the server's OAuth page in a browser tab, we approve, and the token is stored with the connector. If the sign-in page never loads, or completes and the tools still fail, go back to the tree in step 6: Anthropic's cloud has to reach the server, and the server has to accept the account.

ChatGPT connects to MCP servers only as remote connectors, and only after developer mode is switched on. Settings, Connectors (the section is called Apps in some builds), Advanced, Developer mode. Back on the connectors page a + appears with Add custom MCP server. The server needs a public HTTPS endpoint, usually /mcp, with OAuth or no auth, and ChatGPT shows a warning about unverified servers that we accept before it is added.

Which plans get it is the part we could not pin down. As of 28 October 2026 OpenAI's own pages say custom MCP servers with write actions are for Business and Enterprise and Edu, Pro accounts are limited to read and fetch style tools, and sources disagree about Plus. Check in the app: if Developer mode is not under Advanced, the plan does not have it. We will update this line when the help centre settles.

The security warning is not boilerplate. A connector sees whatever the server lets it see, and a server we did not write can return text that tries to steer the model. The same rule as for Claude applies: start with a server we run or a vendor we trust, read-only tools first, and widen once we have watched it work for a week.