Connecting Dr. DNicole to brain.iexdg.com seven paths, one easiest answer
After Apr 26 stalled at the Settings → Connectors UI (no bearer-token field), this is the full landscape of options for getting her Claude Desktop talking to the cloud MCP. Each path scored on her experience: setup minutes, terminal commands she has to type, screen-share friendliness, and how it survives a Claude Desktop update.
For: Robert · Decision: which path next session · Server status: live, 33 tools, bearer auth working
Bottom line
🎯 Recommended: Path G with screen share, falling back to Path A on her keyboard
Path G (build a one-click setup_iexdg_mcp.sh we run via screen share) lets us drive while she watches. Setup is 90 seconds of clicks she sees on her own screen. No paste, no typing, no Terminal mistakes. Path A is the same engineering payload but executed on her keyboard, useful only if screen-share isn't possible. Path B (server-side OAuth) is the right long-term answer for everyone, but it's 2-3 days of server work that fixes future non-technical users, not tomorrow's call with her.
🗺️The seven paths, scored
Decision tree first, then each path's flow, who does what, what breaks, and how she experiences it
A
mcp-remote stdio bridge · she runs it
Node.js · npx · ~15 min on her keyboard
⭐⭐⭐
Setup
⚠️ HIGH
Failure risk
15 min
Time
📥
She does
Download Node.js LTS .pkg from nodejs.org → double-click → click through installer (~3 prompts) → allow security prompt
📧
We send
New claude_desktop_config.json with {"command":"npx","args":["-y","mcp-remote",...]}
📋
She does
Drop the JSON into ~/Library/Application Support/Claude/ via Finder → Cmd+Shift+G
🔄
She does
Cmd+Q Claude Desktop fully → reopen → new chat → type "list your tools"
✅
Verify
She sees ~33 tools from iexdg-pipeline
What works
Standard pattern, well documented
One-time setup, then forgotten
Bearer token stays in config, no UI hunting
If we screen-share, ~3 minutes
What can fail
Node.js .pkg adds npx to Terminal PATH but Claude Desktop spawns processes via launchd which may NOT see it
Apple Silicon vs Intel Node mismatch can break npx invocation silently
If .pkg install fails or she hits "developer cannot be verified", whole flow halts
Same Gmail-line-wrap risk as Apr 26 if we email her commands
How it breaks tomorrow
npx-not-found inside Claude Desktop's spawned process even though it works in Terminal. Fix requires editing config command to absolute path /usr/local/bin/npx or /opt/homebrew/bin/npx. She cannot diagnose this. Without screen share this can stall like Apr 26.
B
OAuth on brain.iexdg.com · native Claude Desktop UI
Server change · 2-3 days · 0 minutes for her
⭐⭐⭐⭐⭐
For her
⏳ HIGH
For us
2 min
Her side
🛠️
We build (research-validated Apr 27)
Migrate the server from mcp 1.27.0 to fastmcp v3.x (jlowin/PrefectHQ fork). Wire OAuthProxy with Google as IdP (DNicole already has Google). FastMCP auto-mounts /.well-known/oauth-authorization-server, /.well-known/oauth-protected-resource, /authorize, /token, /register (DCR per RFC 7591), /auth/callback. Verify GHSA-5h2m-4q8j-pqpj patch status before shipping.
🚢
We deploy
Update Caddyfile, redeploy FastMCP, smoke-test via curl that metadata endpoints return spec-compliant JSON
Browser auto-opens to Cloudflare Access login → one-time email magic link → click link from her email → auto-redirect back → done
✅
Verify
Connector status pill turns green in Settings → new chat → tools available
What works
Her experience is the same as adding any SaaS connector. No technical concepts.
Survives Claude Desktop updates (this IS Anthropic's intended path)
Reusable for every future non-technical user
Token refresh silent. She authorizes once.
Better security than shared bearer (per-user identity, revocable, audit log)
What can fail
2-3 days of focused server work before her side can even start
OAuth metadata bugs are painful to debug remotely
Existing scripts using bearer auth need to keep working during transition (dual-auth period)
Cloudflare Access free tier requires verifying she has a Cloudflare-trusted email; small extra setup
How it breaks tomorrow
It doesn't, on her side. Implementation risk is entirely ours. Once OAuth is live, her flow is the most resilient of all 7. Trade: one weekend of server work to never have this conversation again with her or any future client.
C
Cloudflare Access wrapper · the OAuth shortcut
✗ KILLED Apr 27 · does not support Dynamic Client Registration for non-Workers MCP
✗ DEAD
Confirmed
N/A
No DCR
Workers
Only
🛠️
We configure
Cloudflare Zero Trust dashboard → Access → Application: brain.iexdg.com/mcp → require Google/Microsoft/email-OTP login → enforce on edge
📜
We adjust
Caddy stops checking bearer for /mcp; trust the Cf-Access-Jwt-Assertion header instead. Bearer remains for our scripts via separate path or shared secret with Cloudflare Access service token
⚙️
She does
Same UI flow as Path B: Settings → Connectors → paste URL → browser auth flow
📧
She does
Click email-OTP link → auto-return to Claude Desktop → done
What works
Cuts OAuth implementation work to a few hours of dashboard config + Caddyfile tweak
Cloudflare handles all token lifecycle, refresh, revocation
Free for <50 users (we are 2)
Audit log built-in
What can fail
Claude Desktop's Connectors UI may NOT correctly handle Cloudflare's auth redirect dance (untested · this is the unknown)
If Desktop expects strict OAuth 2.1 metadata endpoints, Cloudflare Access may not match the contract Desktop wants. Need to test.
Existing curl scripts need Cloudflare service token added to maintain access
Why it's dead (research-validated Apr 27)
Two confirmed blockers: (1) Cloudflare Access self-hosted-app mode wraps the VM with its own login + injects Cf-Access-Jwt-Assertion header, but Claude's MCP client cannot complete the browser SSO redirect dance nor send custom CF headers. (2) Cloudflare Access SaaS/OIDC mode does NOT implement RFC 7591 Dynamic Client Registration — Claude Desktop's connector UI requires DCR. Cloudflare's MCP-Access integration only works end-to-end when the MCP server runs as a Cloudflare Worker. Our VM-hosted FastMCP doesn't qualify. Source: developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/saas-mcp/ + GitHub anthropics/claude-code#2527. Skip this path entirely.
D
Python stdio proxy · no Node required
Custom 60-line script · macOS python3 already there
⭐⭐⭐
Setup
⚠️ MED
Failure risk
8 min
Time
📜
We write
Tiny iexdg_mcp_proxy.py (~60 lines) that bridges stdio ↔ HTTPS+bearer using only Python stdlib (json, urllib, sys)
📧
We send
2 attachments: the proxy script + a claude_desktop_config.json that runs python3 ~/iexdg-mcp/proxy.py
📋
She does
Save both files to ~/iexdg-mcp/, drop config into Claude Desktop config dir, restart
✅
Verify
"list your tools" returns 33
What works
Zero install. macOS ships python3 with Xcode CLT, often pre-present
No Node/npm/Apple-Silicon path drama
We control the bridge code, can debug remotely
~80 lines, easy to audit
What can fail
If python3 isn't installed (rare on modern macOS but possible), she has to install Xcode CLT (~1.5 GB, 10 min)
We're maintaining custom protocol code instead of using mcp-remote
Streamable-HTTP transport spec changes would require us to update the proxy
Same JSON-config-in-right-folder failure mode as Path A
How it breaks tomorrow
If macOS doesn't have python3 in launchd's PATH, the proxy never starts. Solution is the same as Path A: use absolute path /usr/bin/python3 in config command.
Web Connectors UI may also be OAuth-only with no bearer field. Same dead end.
What works
Zero local install on her Mac
Survives any Desktop app issue
If her tier and the web UI both support bearer, this is the simplest possible path
What can fail
Web Connectors likely has same "OAuth only, no bearer field" limit as Desktop on her tier
Web has no filesystem access (limits some future MCP tools we may want)
Tier check needed: Custom Connectors are typically Pro+ on web
How it breaks tomorrow
Most likely outcome: same UI shows up with no bearer field. We're back to needing OAuth (Path B/C). Worth verifying her tier first as a 30-second check before committing to anything.
F
Screen-share · we drive her keyboard
Zoom screen control · ~10 min total
⭐⭐⭐⭐⭐
For her
✅ LOW
Failure risk
10 min
Live call
📞
Both
Schedule 15-min Zoom call → she shares screen + grants control
⌨️
We type
Either we install Node + drop config (Path A inside screen share) OR we hand-execute the swap script directly
👀
She watches
Sees what we're doing in real time. Can ask questions live. Builds her confidence.
✅
Verify together
She types "list your tools" with her hand. Confirms herself.
What works
Eliminates Gmail-line-wrap, mistyped commands, "where do I save this", "is it the right folder"
If something fails we see it immediately and recover
She gets a teaching moment, builds Mac literacy
Pairs naturally with Path A or D (any technical path becomes painless via screen share)
What can fail
Requires a synchronous 15-minute window with her
If she has Zoom permission issues granting control (corporate Mac restrictions), we're back to verbal guidance
Doesn't scale to additional users (every new person needs a session)
How it breaks tomorrow
It doesn't break, it just doesn't happen if her schedule is full. The path itself is bulletproof when we're driving. The risk is logistical, not technical.
G
One-click installer + screen share · the recommended path
Pre-built setup_iexdg_mcp.sh · runs everything · ~3 min on call
⭐⭐⭐⭐⭐
For her
✅ LOW
Failure risk
3 min
Live call
🛠️
We build (tonight)
Single setup_iexdg_mcp.sh that: detects Node, opens nodejs.org if missing, waits, retries; writes the bridge config with bearer baked in; restarts Claude Desktop; pings tools/list to verify; reports success or specific failure
📞
Both
15-min Zoom call → she shares screen
📥
She does
Open the email we sent → click the .sh attachment → save to Downloads
⌨️
We narrate
She opens Terminal → pastes ONE line: bash ~/Downloads/setup_iexdg_mcp.sh → presses Return
⏳
Script runs
~60 seconds. Visible progress messages. If Node missing, opens browser to nodejs.org and pauses with clear "click Download, run installer, then press Enter to continue"
✅
Self-verifies
Script ends with: "Installation complete. Cmd+Q Claude Desktop, then reopen, then type 'list your tools' in a new chat. You should see 33 tools." If anything failed, it prints exactly what + how to recover
What works
One paste, four words, no decisions for her to make
Self-healing: script handles every failure mode we hit Apr 26 (Node missing, config missing, file in wrong folder, etc.)
Reusable for any future non-technical user. We just send the .sh and it works.
Works without screen share but better with it (we narrate)
Fully reversible: ship a paired uninstall_iexdg_mcp.sh
What can fail
Apple Gatekeeper may block bash script run from Downloads ("cannot verify developer"). Fix: she Ctrl-clicks → Open. We script around this with xattr -d com.apple.quarantine on first run if needed.
If Claude Desktop's process is wedged, our restart logic (using pkill -f Claude) hits the same blast-radius issue from Apr 26 (Terminal app survives, all Claude processes die · benign but surprising)
Node install during the script is a non-trivial fork that leaves the script in a "wait for human" state
How it breaks tomorrow
Mostly: Gatekeeper. Mitigation is one paste of chmod +x and xattr -d com.apple.quarantine at the top. Build that into the script's first prompt. Other failure: Node install requires user interaction so the script must pause cleanly with a "press Enter when nodejs.org installer finishes" prompt.
📊Side-by-side comparison matrix
All seven paths scored on the dimensions that matter for her
Path
Setup time (her side)
Terminal commands she types
Failure risk
Survives Claude updates
Reusable for next user
Our build effort
Tonight's verdict
A · mcp-remote bridge
15 min
2-3 lines · failure-prone
High
Yes
Some
Already built
Acceptable fallback
B · OAuth on server
2 min
0
Very low
Yes (this is the spec)
Yes (every user)
2-3 days
Right answer · wrong week
C · Cloudflare Access
2 min
0
Medium (untested combo)
Yes if compatible
Yes
~3 hours
Worth a spike
D · Python stdio proxy
8 min
3-4 lines
Medium
Yes
Some
~2 hours
Backup option
E · claude.ai web
3 min
0
Unknown
N/A
Yes
Just verify tier
30-second check first
F · Pure screen share
10 min
0 (we drive)
Very low
N/A (we redo each update)
No (one-by-one)
0
Solid plan B
G · Installer + share
3 min
1 line
Very low
Yes
Yes (best · just resend .sh)
~3 hours tonight
RECOMMENDED
🧭How to decide
Two-dimensional read on cost vs her experience
The decision in plain language
Three paths actually compete for tomorrow's call:
Path G (installer + screen share): 3 hours of build tonight, 3 minutes on the call, almost zero failure risk, reusable for every future client. The right answer for tomorrow.
Path A (bridge on her keyboard): zero build, but high failure risk on her side. Acceptable only if we cannot screen-share and we trust her to copy-paste perfectly. Apr 26 proved we can't.
Path B (OAuth on server): the right structural answer, but a 2-3 day build that doesn't help tomorrow and risks shipping half-implemented if rushed. Schedule it for a focused weekend.
Paths C, D, E are interesting backups. Path F (pure screen share without an installer) is what we'd do if Path G's build hits a snag tonight. Combine them as the layered fallback strategy.
Recommended sequence
Tonight: build Path G. This week: schedule Path B for the weekend.
1. Tonight (~3 hours): Write setup_iexdg_mcp.sh. Pair it with uninstall_iexdg_mcp.sh. Smoke-test it on Robert's Mac (or a VM) end to end. Email her with one paste-line of instructions and the .sh attachment.
2. Tomorrow (~15 min Zoom): Screen-share. She runs the one paste. Verify together. Done.
3. This weekend (~14-16 hours over 2 days): Build Path B per research-validated design. Migrate mcp 1.27.0 → fastmcp v3.x. Add GoogleProvider + OAuthProxy. Update Caddyfile with handle blocks for the 7 OAuth metadata + auth routes (per feedback_caddy_route_vs_handle.md rule). Run dual-process bearer + OAuth side-by-side for 7 days, then sunset bearer for human users. Cloudflare Access ruled out: doesn't support DCR for non-Workers MCP servers.
Once Path B ships, every future client onboards in 2 minutes via the Settings UI with no installer, no screen share, no Terminal. That's the long-term payoff.