Skip to content

Client Compatibility

Jump to bottom
Jm Rohmer edited this page Aug 20, 2026 · 7 revisions

Client Compatibility

This page tracks client-facing expectations. Treat live client behavior as drift-prone and re-test before claiming support after OAuth or discovery changes.

Current Client Targets

Client Expected behavior
Claude.ai custom connector OAuth + MCP discovery; a client with the write scope should see the full write/build/diagnostic tool set (everything except the four admin-gated Hugo lifecycle tools) after authenticated reconnect
Claude Desktop Connects to https://mcp.arleo.eu/mcp with MCP-compatible discovery
ChatGPT custom connector Compatible MCP client; actual tool availability is plan-dependent. The tested Plus account currently stops after initialize; see Pitfall ChatGPT Plus MCP Availability
Le Chat custom connector OAuth flow and scoped tool access, same 3-tier (read/write/admin) model as the other clients
MCP Inspector Anonymous read-only MCP inspection

Correction (v1.9.2 docs pass). This page previously said "since #450 there is no separate admin scope" — that described the model before #1039/#1050 extended it to a genuine three-tier read/write/admin. admin is now a separately-approved tier on top of write, gating only the four managed Hugo binary lifecycle tools (stage_hugo_upgrade, activate_hugo, rollback_hugo, bootstrap_hugo) — it does not narrow or replace write. See OAuth Clients and Scopes and Scope and Tool Matrix for the current, authoritative model.

URLs to Configure

Use the MCP endpoint for MCP clients:

https://mcp.arleo.eu/mcp

OAuth issuer:

https://mcp.arleo.eu

Do not configure the MCP endpoint as https://mcp.arleo.eu unless a client explicitly expects the issuer/base URL. /mcp is the JSON-RPC MCP endpoint.

Claude.ai Notes

If Claude connects but only shows anonymous/read-only tools:

  1. Remove and recreate the connector to clear client-side cache.
  2. Confirm the OAuth flow grants the intended scope.
  3. Confirm tools/list is called with Authorization: Bearer ....
  4. Confirm /mcp responses include cache controls that prevent an anonymous tool list from being reused for an authenticated request.
  5. Confirm admin tools are gated by the token scope, not by client_id alone.

Useful headers for /mcp:

Cache-Control: no-store
Vary: Authorization
WWW-Authenticate: Bearer ...

ChatGPT Notes

ChatGPT redirect URI handling is strict. Do not allow arbitrary redirect URIs to fix a client issue.

Expected policy:

  • accepted: known HTTPS callbacks for ChatGPT
  • rejected: HTTP, similar malicious hosts, unknown domains, wrong paths
  • unknown DCR clients: no write/admin escalation

Known issue (2026-08-20): ChatGPT shows "not all authorizations granted" / empty Actions despite a fully successful server-side connection

Reproduced live against hugo-vm, both with the pre-existing connector and a freshly created one (manually-configured chatgpt-write OAuth client, not DCR). Symptom in the ChatGPT UI: an orange "Hugo MCP on www.arleo.eu est connecté, mais toutes les autorisations demandées n'ont pas été accordées" banner, then "Actions: Aucune action de l'application n'est disponible pour le moment" — zero tools ever show up, and asking the model to use the connector gets an honest "I can't find it in the tools available to this runtime" from ChatGPT itself.

Every layer up to and including MCP session creation is confirmed correct server-side. journalctl -u mcp-hugo-server-go for the exact window of a reconnect attempt shows this pattern repeat 5 times in one session, every single time ending in success:

POST /mcp (no Authorization header)         -> 401 missing_bearer (expected: RFC 6750 §3.1 discovery trigger)
GET .well-known/oauth-protected-resource    -> 200
GET .well-known/oauth-authorization-server  -> 200
GET .well-known/openid-configuration        -> 404 (expected, see [[Pitfall openid-configuration 404]])
mcp: session created scope=write rank=1     -> POST /mcp -> 200

Also confirmed: the freshly-created connector correctly requested scope=read write (current canonical form, checkboxes shown directly in ChatGPT's own connector setup UI: read ✓, write ✓, admin ☐) — ruling out an earlier theory that ChatGPT was requesting stale pre-#450 legacy scope strings.

The actual gap: in every one of these 5 cycles, exactly one POST /mcp request is logged (the initialize call) and then nothing — no follow-up tools/list ever arrives. ChatGPT's client appears to treat the successful initialize response as the end of the attempt and never continues the MCP handshake to ask for tools. The server logs cannot reveal which client-side eligibility or validation check causes that decision.

Update (same day, confirmed via a second reproduction and a control test): re-tested with a fully fresh Dynamic Client Registration connector (not the pre-registered chatgpt-write static client). DCR itself worked correctly — POST /register succeeded, scope=read write admin was correctly clamped to read (DCR-registered clients get a read-only ceiling by design), token issued, session created, 200 returned. 35 seconds later, ChatGPT restarted the entire OAuth+MCP handshake from scratch — fresh discovery, fresh /authorize, fresh token exchange, fresh session — rather than continuing the session it already had with a tools/list call. Same one-POST /mcp-then-nothing pattern both times.

Control test, same server, same time window: MCPJam (a dedicated MCP debugging client) ran the identical flow — discovery, DCR, scope=read write admin clamped to read (identical clamping behavior), PKCE, token — and then made multiple real follow-up POST /mcp calls with actual processing time (25ms, 30ms, one GET /mcp at 331ms), successfully retrieving tools/resources/prompts. MCPJam's own summary: "0 warnings, 0 errors — everything proceeded as expected."

Binary-identity check (the strongest evidence here): the operator pushed back that this connector "was working fine a while ago" — a fair challenge, since a claim of "client bug" needs to survive that. Checked: /usr/local/bin/mcp-hugo-server-go on hugo-vm had mtime 2026-08-16 17:19, unchanged, right up until this investigation. journalctl confirms a real, complete, successful session for this exact chatgpt-write client on 2026-08-17 06:53:59 — authorize -> token -> session created -> multiple /mcp calls -> tool_call: get_capabilities -> success. The regular refresh_token cadence (every few hours) continues cleanly through 2026-08-17 22:49:39, then stops; the next entry is a fresh authorize on 2026-08-20 07:43:20, and every attempt from that point on (5+, across the static client, a fresh DCR client, and multiple ChatGPT UI retries) exhibits the broken one-request-then-abandon pattern described above.

Since the server binary is byte-for-byte unchanged between the last known-good session (Aug 17) and the first observed failure (Aug 20), the server cannot be the source of the behavior change — there is no code or config diff to point to. Whatever changed happened in that ~2-day gap on the client side. The ChatGPT connector UI shows "Nom de la version: dev mode" / "Statut de l'examen: development" (OpenAI's Apps SDK connector framework, still actively evolving) — consistent with a client-side update landing in that window.

Status: ChatGPT remains a compatible MCP client, but the tested ChatGPT Plus account is not currently usable. The unchanged server binary bracketing a known-good session and the first-observed-broken session proves that this was not introduced by a server release. It does not establish the behavior of Pro, Business, Enterprise, or Edu accounts. Nothing under this project's control was found broken across the pre-registered static client, a fresh DCR client, or the MCPJam control test. Suggested next steps if revisited: (1) file feedback via help.openai.com as ChatGPT's own error banner suggests, including this exact log pattern, the Aug 17-vs-Aug 20 comparison, and the MCPJam control-test contrast; (2) if OpenAI ships an updated connector client, re-test with a fresh connector before assuming it's fixed.

OpenAI's public documentation is inconsistent as of 2026-08-20: its developer-mode guide lists Plus among eligible accounts, while the Help Center availability article limits full MCP to Business/Enterprise/Edu, describes Pro as read/fetch-only, and omits Plus. See Pitfall ChatGPT Plus MCP Availability for the concise operator decision tree.

Interop Smoke

Run:

SMOKE_LIVE=1 ./scripts/smoke-agent-interop.sh

Optional bearer-token checks should be provided via environment variables and must never be printed in logs:

READ_BEARER=REDACTED ADMIN_BEARER=REDACTED SMOKE_LIVE=1 ./scripts/smoke-agent-interop.sh

Before sharing output publicly, redact any bearer token, authorization code, client secret, or cookie.

Clone this wiki locally