Anonymous and unauthenticated users
This page explains how ChatGPT (and similar MCP hosts) work with Agentsyx when the end user starts without a full Agentsyx account, then moves to a real account—the mixed auth path—and what your MCP app and downstream server should expect.
For HTTP headers on your MCP URL, see Inputs to downstream servers. For attaching the app in ChatGPT, see Register in ChatGPT (OpenAI).
Request path (who calls whom)
End-user clients such as ChatGPT call the Agentsyx MCP endpoint. They do not call your downstream MCP server URL directly. Agentsyx authenticates and bills the caller and proxies traffic to your connector URL. The inputs reference documents the body and headers your server receives on that hop.
Identity and merge headers (downstream)
On proxied tools/call requests, use documented x-a6-* HTTP headers to read anonymous vs authenticated context, any short anonymous handle the platform exposes, merge history, and related fields. Do not assume specific JSON-RPC params._meta keys are present on the downstream hop unless your integration contract explicitly says so.
What “merge” means for your app (duplicate user UUIDs)
First-time linking—anonymous usage later tied to a new account—is ordinary product flow. The x-a6-merged-user-uuid header is about a different problem: the platform may end up with more than one user UUID for what is effectively the same end user (for example anonymous activity under one UUID, sign-up under another, and a further UUID created by a mixed host + portal path). Agentsyx can collapse those platform-side records and tell you which UUIDs are superseded.
Your job is data reconciliation, not “grant identity the first time.” When x-a6-merged-user-uuid is present, treat the listed UUIDs as additional keys your app may have used to store chats, settings, or other per-user state. Move or alias that state so it belongs to the current canonical user (x-a6-user-uuid and related headers when provided). If you skip this, the customer sees split history or orphaned data even though Agentsyx already unified accounts upstream.
When applicable, x-a6-merged-user-uuid lists those prior user records the platform has merged into the current user for this request.
Merge signals are not automatic data migration. Agentsyx performs platform-side merge and bookkeeping; it does not rewrite rows in your database. Your downstream MCP server must read the headers you care about and reconcile durable state idempotently (retries and repeat requests should not double-apply or fork data). The numbered checklist for x-a6-merged-user-uuid is in Inputs to downstream servers.
Reference scenario: Chat Vault
Chat Vault is the reference app used in Agentsyx examples. The user saves chats while anonymous; Chat Vault keys those rows by x-a6-user-uuid (and related x-a6-* fields) on each downstream call. They open an Agentsyx-provided portal link, register, and continue—possibly under a different platform user UUID than before. Later, the same person uses ChatGPT again and, in an edge path, the platform briefly associates another user UUID with the same anonymous customer journey. Agentsyx then merges the duplicate platform users and sends x-a6-merged-user-uuid listing the older UUIDs. Chat Vault must merge user data: re-key or join every chat row stored under any listed UUID into the current canonical user, idempotently, until repeat requests are a no-op. That is the merge contract—not merely the first moment an anonymous user gains an account.
ChatGPT path vs in-app embedding
- ChatGPT / OAuth: The user signs in through OAuth to Agentsyx (per OpenAI’s connector flow). Your downstream server should use
x-a6-*headers per the inputs reference to distinguish anonymous and authenticated callers. - In-app embedding: Some Agentsyx UIs call MCP through an internal HTTP proxy that attaches a session token. That is a different surface from ChatGPT’s OAuth model; do not assume it is the only way identity reaches your tools.
What to read on the wire (downstream)
| Concept | What it is |
|---|---|
params.arguments | The JSON object of tool inputs from the model (your schema). |
params._meta | Optional MCP metadata on params (sibling of name and arguments). May be present depending on client and proxy; prefer x-a6-* headers for identity-related behavior on your connector. |
x-a6-* headers | Platform-supplied HTTP headers on requests to your MCP URL—see Inputs to downstream servers. |
Mixed-auth lifecycle
Phase A — Anonymous plan (no real account yet)
The end user can use the MCP app within the limits of the anonymous subscription. Downstream, read x-a6-is-anon-user, x-a6-short-anon-id, x-a6-anonymous-subscription, x-a6-portal-link, x-a6-login-link, and related x-a6-* fields when Agentsyx has that context (see the inputs reference).
Treat this as “free / no durable human identity” for product purposes: you may limit features, cap storage, or require sign-in for sensitive actions—even though upstream billing and credits are still enforced by Agentsyx.
Phase B — Upgrade (portal / sign-in)
When the user should create or link a real account, the MCP App (widget) or tool responses can steer them to the portal or sign-in URL Agentsyx provides. Those URLs are constructed so that, after sign-up or sign-in, Agentsyx can associate prior anonymous usage with the authenticated user.
Phase C — Account created
Once the user has an account with Agentsyx, they are no longer on the anonymous plan for that linkage. Subscription and billing context follow the real user.
Phase D — Merge in Agentsyx
When the platform detects multiple user UUIDs that should represent one customer (anonymous + sign-up + rare duplicate paths), Agentsyx merges those records on its side and remembers which UUIDs were superseded. That is separate from the ordinary “upgrade from anonymous” moment—merge is about deduplicating identity when two or more UUIDs existed. Do not depend on internal storage details—only on the headers documented for downstream use.
Phase E — Calls after merge
Subsequent tools/call traffic may include x-a6-user-uuid, x-a6-username, x-a6-email, and x-a6-merged-user-uuid (comma-separated UUIDs of former user records merged into the current user). Downstream: reconcile any data you stored under those former UUIDs into the current user—see What “merge” means for your app above; for a concise checklist, see Inputs to downstream servers.
Two user shapes (what to implement in your app)
- Anonymous shape — Downstream keys:
x-a6-user-uuid(when the platform assigns one for anonymous usage) andx-a6-short-anon-id/x-a6-is-anon-useras needed—see the inputs reference. Do not assume email or real name exists. - Authenticated shape — Stable key: platform user identity (via
x-a6-*identity headers when present). When the platform has collapsed duplicate user records,x-a6-merged-user-uuidlists prior UUIDs your downstream MCP server must reconcile into that canonical user (see What “merge” means for your app above).
Downstream obligation: When x-a6-merged-user-uuid is provided, the downstream MCP server must merge user data: fold every row keyed by a listed UUID into the current user, track which merges were applied, and keep handling idempotent. See What “merge” means for your app above and the checklist in Inputs to downstream servers.
Edge case (the one merge is for): The same anonymous customer journey ends up with a second (or third) platform user UUID—for example portal sign-up produced one UUID and a later ChatGPT path produced another. Agentsyx merges those identities upstream; your app must still move or alias stored data when x-a6-merged-user-uuid appears so nothing stays stranded under an old UUID.
Flow overview (ChatGPT → upgrade → merge)
sequenceDiagram
participant Host as ChatGPT
participant Platform as Agentsyx
participant Downstream as YourMCP
participant User as EndUser
Host->>Platform: tools/call upstream
Platform->>Downstream: JSON-RPC plus x-a6 anon headers when provided
Note over Downstream: Limited features or errors with portal hint
User->>Platform: Open portal or sign-in URL from platform
User->>Platform: Complete sign-up or sign-in
Platform->>Platform: Collapse duplicate user UUIDs when needed
Host->>Platform: Later tools/call
Platform->>Downstream: JSON-RPC plus identity and x-a6-merged-user-uuid when applicablePractical guidance
- Downstream, implement anonymous-aware tools against
x-a6-*headers and safe defaults when they are missing. - Do not re-implement subscription or credit enforcement in place of Agentsyx; still gate expensive side effects in your own tools if needed.
- Rate-limit high-cost operations if anonymous users can trigger them.
For optional MCP _meta at a high level, see Injected parameters & metadata.