DEV Community

Mohab Abdelkarim
Mohab Abdelkarim

Posted on

One MCP Server, Three Assistants: Running Walter Across Claude, ChatGPT, and Codex

TL;DR: One MCP server, https://mcp-server.walterwrites.ai/mcp, now works across three completely different AI clients: Claude (stable, native connector support), ChatGPT (beta, via Developer Mode), and Codex (native CLI/IDE support). Same tools, same detection and humanization logic, three different setup flows. This post covers the actual config for all three, what's different about each, and why this is a genuinely interesting case study in MCP interoperability even if you don't care about Walter specifically.


Six months ago, this would've been a one-platform story. Walter's MCP server, which exposes AI text humanization and detection as callable tools, only worked inside Claude. If your team drafted in ChatGPT, or you were building internal tooling on top of Codex, you were stuck with the old copy-paste-detect-copy-paste-humanize loop that MCP exists specifically to kill.

That's no longer true, and the reason it's no longer true is a good, concrete example of what the M×N integration problem MCP was built to solve actually looks like when it's solved. One server. Three clients. Zero custom integration code written on Walter's side to support any of them.

Here's the setup for all three, the actual differences in how each client handles tool calling, and a few things that will save you time if you're setting this up yourself.

Why this is worth a post beyond "here's how to add a connector"

If you've built or used more than one MCP server, you already know the theory: implement the spec once, any compliant host can use it. What's actually interesting here is watching that promise hold up (or not) across three hosts with meaningfully different maturity levels.

Claude's MCP client implementation has been stable for a while. Tool selection is reliable, you don't need to over-specify a prompt, and the connector setup is entirely GUI-driven.

ChatGPT's MCP support (branded "Developer Mode," previously part of what OpenAI called "connectors" until a December 2025 rename to "apps") is newer and still in beta. Tool selection is noticeably less reliable, meaning you have to write more explicit prompts to guarantee it reaches for the right tool instead of falling back to something built-in like web search.

Codex has had MCP client support in the CLI and IDE extension for a while, configured through a shared config.toml, and it's the only one of the three with zero web UI involved in setup.

Same protocol. Three different levels of client maturity. If you're building your own MCP server and wondering how much you need to defensively prompt-engineer around client-side tool selection quirks, this is a useful real-world data point.

The server side, briefly

Walter's MCP server runs as a single remote, authenticated endpoint:

https://mcp-server.walterwrites.ai/mcp
Enter fullscreen mode Exit fullscreen mode

It's a streamable HTTP server (not stdio), which is the relevant detail for Codex config later. It exposes two main tools relevant here, humanize and detect, both callable the same way regardless of which client is invoking them. Same server-side logic. The differences below are entirely client-side.

Setup 1: Claude (the baseline, simplest of the three)

If you've set up any MCP connector in Claude before, this is nothing new.

  1. Settings → Connectors → click +
  2. Select Add custom connector
  3. Fill in:
Name: Walter Writes AI
Remote MCP Server URL: https://mcp-server.walterwrites.ai/mcp
Enter fullscreen mode Exit fullscreen mode
  1. Click Add, sign in with your Walter account, click Allow Access

That's it. No further prompt engineering required, in practice Claude reliably picks the right tool from a normal, unscaffolded prompt like:

Humanize this draft with Walter, then run detection on the result.
Enter fullscreen mode Exit fullscreen mode

Setup 2: ChatGPT (beta, more moving parts)

This is currently gated to Pro and Plus accounts on ChatGPT web (plus Business/Enterprise/Education workspaces where an admin has enabled it). A few things to know before you start:

  • As of mid-December 2025, OpenAI renamed "connectors" to "apps." If you're looking at older docs or screenshots and can't find "Connectors" in settings, that's why.
  • Developer Mode gives ChatGPT full MCP client support, meaning both read and write tool calls, not the older fetch-only connector model.

Setup:

  1. Settings → Apps → Advanced settings
  2. Enable Developer mode
  3. Click Create app
  4. Fill in:
Name: Walter Writes AI
MCP Server URL: https://mcp-server.walterwrites.ai/mcp
Authentication: OAuth
Enter fullscreen mode Exit fullscreen mode

Leave the Client ID/Secret fields blank, Walter's server handles the OAuth exchange automatically once you authenticate.

  1. Check I trust this application → Create
  2. Sign in to Walter when prompted
  3. Confirm the app shows as connected

One more step before it's usable mid-conversation: in chat, click +More → enable the Walter Writes connector.

The prompting gotcha

This is the part that actually matters if you want this to work reliably. Because Developer Mode is beta, ChatGPT does not consistently infer that it should call a custom tool over falling back to something built-in. A vague prompt like "make this sound more human" might silently just get ChatGPT's own rewrite instead of an actual Walter tool call.

Fix: be explicit. Name the connector, name the exact action, specify what to return, and tell it not to use web search.

Using the Walter Writes MCP connector, run the humanize action on the
draft below, then run the detect action on the result. Return the
readability score, AI score, and a short change summary. Do not use
web search.

[paste draft]
Enter fullscreen mode Exit fullscreen mode

Verbose, yes. Necessary right now, also yes. Check the tool call preview in the response to confirm Walter's tools are actually what got invoked, not a built-in fallback.

Setup 3: Codex (fastest, zero UI)

If you're already comfortable in a terminal, this is the quickest of the three.

Option A, one command:

codex mcp add walterwrites --url https://mcp-server.walterwrites.ai/mcp
Enter fullscreen mode Exit fullscreen mode

Option B, edit config directly. Codex stores MCP server definitions in ~/.codex/config.toml (global) or a project-scoped .codex/config.toml (only loads for directories Codex has marked trusted):

[mcp_servers.walterwrites]
url = "https://mcp-server.walterwrites.ai/mcp"
Enter fullscreen mode Exit fullscreen mode

Authenticate (same OAuth flow as the other two, just CLI-triggered):

codex mcp login walterwrites
Enter fullscreen mode Exit fullscreen mode

Verify:

codex mcp list
Enter fullscreen mode Exit fullscreen mode

You should see walterwrites listed as active. Inside an interactive session, /mcp shows currently connected servers too.

Codex will reach for Walter's tools automatically once configured. If you want that to happen without a confirmation prompt every time, set an approval_mode on the tool (auto, prompt, or approve):

[mcp_servers.walterwrites]
url = "https://mcp-server.walterwrites.ai/mcp"
approval_mode = "auto"
Enter fullscreen mode Exit fullscreen mode

For consistent behavior across a whole project without repeating instructions every session, drop a line into AGENTS.md:

Use Walter's humanize and detect tools automatically for any content
that needs AI-detection review or humanization before it's finalized.
Enter fullscreen mode Exit fullscreen mode

This matters specifically for developer-facing content, README files, doc comments, CHANGELOG entries, anything written inline in a repo that might read as obviously AI-generated and would benefit from a pass before it ships.

stdio vs streamable HTTP, since it comes up

Quick clarification since this trips people up in Codex specifically: stdio servers run as a local process, spawned and piped to directly by the client. Streamable HTTP servers (what Walter uses) are remote, accessed by URL, and support OAuth or bearer token auth. That's why Walter gets added with --url in Codex rather than a local command, it's not a process Codex spawns, it's a remote endpoint Codex calls over HTTP.

Where each one actually makes sense

Not trying to force a false equivalence here, each of the three genuinely fits a different workflow:

Claude for long-form content pipelines. Tool selection just works, so it's the lowest-friction option if you're doing this regularly and don't want to think about prompt scaffolding.

ChatGPT if your team is already standardized there and switching tools just for humanization isn't worth the context switch. Budget for more explicit prompts and occasional manual tool-call confirmation until Developer Mode matures.

Codex specifically for anything developer-facing that lives inside a repo, docs, comments, generated changelogs. It's also just the fastest to set up if you're not touching a browser at all.

Common failure modes

  • ChatGPT: connector doesn't show up after creating it. Start a new chat. Developer Mode changes sometimes don't reflect in an existing conversation's tool list.
  • ChatGPT: keeps using web search instead of Walter. Prompt wasn't explicit enough, see the gotcha section above.
  • ChatGPT: Developer Mode isn't in Settings at all. Confirm you're on web (not mobile) and on a Pro/Plus account or a workspace where an admin enabled it.
  • Codex: tool call times out. Default timeout is 60s. Bump tool_timeout_sec in the server's config block if a specific call needs more.
  • Codex: project-level config not loading. Only loads for directories Codex has explicitly marked trusted, check that first.
  • Any client: OAuth won't complete. Usually a pop-up blocker or browser extension eating the redirect. Check that before assuming the server's broken.

Closing thought

The interesting part of this isn't really "Walter now works in three places." It's that it required zero server-side changes to get there, that's the actual point of MCP as a spec. What differs entirely is client-side maturity: Claude's implementation just works, ChatGPT's needs more explicit handholding right now because it's newer, and Codex trades a GUI for two terminal commands. If you're building your own MCP server, that maturity gap across hosts is worth planning around, because your users are going to hit it regardless of how well you've built your server.

Docs for all three setups: docs.walterwrites.ai. Server: walterwrites.ai.


FAQ

Does the same account work across all three?
Yes, all three authenticate against the same Walter account via OAuth. Word balance, settings, and history carry over.

Is Codex MCP support free?
The MCP client functionality itself has no separate cost, you need an active Codex/ChatGPT account with the right access tier, plus a Walter account for the humanization credits the actual tool calls consume.

Do I need a paid ChatGPT plan?
Yes, currently. Developer Mode requires Pro or Plus individually, or a Business/Enterprise/Education workspace where an admin has turned it on.

Why does ChatGPT need more explicit prompts than Claude?
Claude's MCP implementation has been stable longer and reliably infers the right tool from context. ChatGPT's Developer Mode is newer and still beta, tool selection isn't as consistent yet, so explicit naming of the connector and action is currently required for reliable behavior.

Top comments (0)