Connect Your Clients

Connecting ChatGPT and Other MCP-Compatible Clients

⏱ 13 min

The previous two lessons had a simple, consistent shape: give the client a URL, give it an Authorization header carrying your Application Password, done. ChatGPT doesn’t follow that same shape, and pretending it does would set you up to fail. This lesson is honest about where ChatGPT’s remote MCP support actually is today, and what your realistic options are for a WordPress server that authenticates with Application Passwords rather than OAuth.

What you'll learn in this lesson
How ChatGPT exposes custom MCP servers
Developer Mode, what it is, who has access to it, and how it differs from a one-click Apps Directory install.
Why OAuth is the friction point
ChatGPT's connector setup is built around OAuth, while the MCP Adapter has no OAuth support at all.
The confirmation flow for write actions
What ChatGPT actually shows you before it lets a tool call change something.
Realistic options for a header-authenticated server
What to do given the gap, without overselling a workaround as officially supported.
What "other MCP-compatible clients" means in practice
How to evaluate any new client you encounter using the same checklist.
Prerequisites

The same MCP server and endpoint URL from the previous two lessons. A ChatGPT account on a plan that includes Developer Mode (Plus, Pro, Business, Enterprise, or Education, on the web app at the time of writing). No code changes to your server are required for this lesson, this is entirely about the client side and what’s realistic.

Developer Mode: what it actually is

ChatGPT’s mechanism for connecting to a server you built yourself is called Developer Mode, and it’s explicitly labeled a beta feature. It’s found in ChatGPT’s settings, under the area for connectors or apps, with an “Advanced” section containing the Developer Mode toggle. Once enabled, you can add a custom MCP server by providing its URL, similar in spirit to Claude and Cursor, but the resemblance mostly ends there.

This is different from installing an app from ChatGPT’s Apps Directory, which is a one-click flow for MCP servers that have already been published and reviewed. Your WordPress site isn’t a published app, so Developer Mode, not the Apps Directory, is the relevant path.

The real friction: authentication

Here’s the part worth being direct about. When you add a custom connector in Developer Mode, ChatGPT expects one of a small set of authentication modes, and its setup flow is built around OAuth: you give it a server URL, set the authentication mode, and if that mode is OAuth, ChatGPT expects your server to run a full OAuth 2.1 authorization flow conforming to the MCP authorization spec, redirecting the user to log in and approve access.

Your WordPress MCP server doesn’t do that. As stated plainly in Course 2, the MCP Adapter authenticates with Application Passwords or cookie/nonce auth, there is no OAuth in the adapter itself. That’s not a gap in your setup, it’s the current state of the official plugin. It means the clean, “paste a URL and a header” experience you had with Claude Desktop and Cursor doesn’t have an equally clean equivalent here.

Don't assume a header field behaves like Claude's or Cursor's

Some ChatGPT connector flows expose an option other than OAuth for servers that don’t need a login redirect, but treat this as something to check directly inside your own ChatGPT settings at the time you’re reading this, not something to assume works identically to Claude Desktop’s headers object in claude_desktop_config.json. Client UIs in this space change fast. Confirm what your version actually offers before building a workflow around it.

Your realistic options today

Given that gap, you have three honest paths, not one “correct” answer:

  1. Don’t connect ChatGPT to a live, write-capable WordPress server yet. If your registered abilities can create posts, change settings, or do anything you wouldn’t want reachable without strong auth, and your only option in ChatGPT is a no-authentication connection, skip it for now and keep using Claude Desktop or Cursor for that server. This is the safest default.
  2. Put a small authenticating proxy in front of your MCP endpoint that terminates an OAuth flow ChatGPT can complete, then forwards the authenticated request to your WordPress site using a securely stored Application Password on the server side. This is a legitimate pattern, but it’s infrastructure you build and maintain yourself, it isn’t something the MCP Adapter or ChatGPT hands you for free, and Course 4 is where the security implications of any proxy like this belong.
  3. Use a read-only, low-stakes ability if you do want to experiment with ChatGPT against a connection with weaker authentication, something like “list published post titles” rather than anything that writes or deletes.
A write-capable tool without real auth is not a demo, it's an exposure

ChatGPT itself warns that write actions can occur even when a server marks an action as read-only, and that you shouldn’t connect to a custom MCP server you don’t trust. The same caution applies in the other direction: don’t expose a write-capable WordPress ability behind weak or no authentication just to make a ChatGPT demo work.

What ChatGPT does get right: the confirmation flow

Where ChatGPT’s Developer Mode is genuinely solid is its confirmation step. Before executing anything ChatGPT considers a write or mutating action, it stops and shows you the proposed tool call, asking you to confirm before sending the request to your server. This is the same principle Lesson 6 in this course teaches you to build directly into your own abilities, ChatGPT is applying a version of it at the client level, on top of whatever your server itself provides.

Test it, if your setup supports it

If you’ve confirmed your specific ChatGPT settings offer an authentication mode your server can actually satisfy, the test is the same shape as the previous two lessons. Ask it to list available tools first, then invoke one:

You: "What tools does the WordPress connector make available?"
You: "Use the WordPress tool to list the five most recent draft posts."

A working connection shows ChatGPT naming your tool specifically and returning data that matches what’s actually in wp-admin, along with a confirmation prompt if the action qualifies as a write.

Other MCP-compatible clients

New MCP clients keep appearing, IDE assistants, agent frameworks, custom scripts. When you evaluate one you haven’t used before, run through the same three questions this course has covered for Claude, Cursor, and ChatGPT:

Questions to ask any new MCP client
Does it take a plain URL and header?
If so, it likely works exactly like Claude Desktop and Cursor with your Application Password.
Does it require OAuth?
If so, you're in ChatGPT's situation, and need a proxy or a different auth story before connecting anything sensitive.
Does it show you tool calls before running them?
Confirm this before trusting it with anything beyond read-only abilities.

Recap

ChatGPT’s Developer Mode lets you add a custom MCP server, but its setup is built around OAuth, which the official MCP Adapter doesn’t implement, so the smooth URL-plus-header connection you got with Claude Desktop and Cursor doesn’t carry over cleanly. Until you build or adopt an authenticating proxy, treat ChatGPT as appropriate for read-only, low-stakes abilities only, and evaluate any other new MCP client using the same three questions: URL and header, OAuth requirement, and confirmation behavior.

Resources & further reading

← Connecting Cursor to Your MCP Server Building a Conversational WordPress Admin Assistant →