Inputs to downstream servers
Reference for the JSON-RPC body and HTTP headers on requests that Agentsyx forwards to your downstream MCP server URL—the endpoint you configure on your connector.
For who calls whom (ChatGPT → Agentsyx → your connector), anonymous vs authenticated lifecycle, merge semantics, and the Chat Vault walkthrough, see Anonymous and unauthenticated users.
Request body
jsonrpc,method,id— Standard JSON-RPC.params— Fortools/call, MCP uses an object that includes:name— Tool name. Agentsyx may rename tools before your server sees the call; implement thenameyou actually receive.arguments— JSON object of inputs for the tool (what the model filled in for your tool schema)._meta(optional) — A separate JSON object onparams, not insidearguments. MCP allows metadata here; presence and keys vary by client and proxy. For anonymous identity on your connector, prefer documentedx-a6-*headers. Overview: Injected parameters & metadata.
HTTP headers
Agentsyx sets Content-Type: application/json and typically Accept: application/json, text/event-stream on POSTs to your MCP URL.
Authorization — Usually Bearer plus the API key / credential configured in Agentsyx Creator on the Downstream connector form for your MCP URL. Agentsyx forwards that value on each outbound call so your server can authenticate the caller.
Strong recommendation: Your downstream MCP server should verify this credential on every request (compare the presented Bearer token—or vendor-equivalent scheme—to the API key your deployment expects). Reject missing or invalid credentials (for example 401 or 403). The value Agentsyx sends is the one from the Downstream connector form; your server must enforce it—do not assume URL secrecy alone is enough, or anyone who can reach your MCP endpoint could invoke tools. Keep the expected key only in secrets or secure config on your side.
Other headers the platform may include when it calls your MCP (not all appear on every request):
| Header | Purpose |
|---|---|
x-service-user-key | Service-user key for billing / attribution when the platform uses that model. |
x-user-token | Opaque user token when the platform passes one for your connector. |
x-ref-uuid | Reference UUID when the platform attaches one for correlation. |
mcp-session-id | MCP session id when session continuity is in use for that connection. |
x-a6-* headers (platform → your downstream URL)
These may be present when Agentsyx has the corresponding context (anonymous users, links, identity chaining, account merges). Omit handling for any you do not need.
| Header | Typical value | Meaning (for your server) |
|---|---|---|
x-a6-short-anon-id | opaque string | Short anonymous id when the end user is or was anonymous. |
x-a6-is-anon-user | true or false | Whether the platform classifies the caller as anonymous. |
x-a6-anonymous-subscription | true or false | Anonymous-plan / tier context when applicable. |
x-a6-portal-link | URL | Portal URL for upgrade or account flows when supplied. |
x-a6-login-link | URL | Login URL when supplied. |
x-a6-user-uuid | UUID | End-user id when the platform forwards identity (e.g. some chained MCP scenarios). |
x-a6-username | string | Username when forwarded with identity. |
x-a6-email | string | Email when forwarded with identity. |
x-a6-merged-user-uuid | comma-separated UUIDs | UUIDs of prior platform user records Agentsyx has superseded—typically because more than one user UUID was created for the same end user (anonymous + sign-up + duplicate paths). Your downstream MCP server must merge user data keyed by those UUIDs into the current user. See below. |
Unknown x-a6-* names may appear as the platform evolves—log and ignore, or follow release notes if you depend on new fields.
Downstream responsibility for merged UUIDs
This header exists for duplicate platform user UUIDs: the same customer may briefly have two or more user ids (for example anonymous usage vs portal registration vs a later host path). Agentsyx unifies those records upstream and lists the old ids here. First-time anonymous-to-account linking is normal; this header means “you may have stored data under other UUIDs—fold them in.”
When x-a6-merged-user-uuid is present on a request, it is your downstream MCP server’s job to:
- Merge user data — Move or alias any durable state you keyed by those listed UUIDs so it lines up with the current user (using
x-a6-user-uuidand related headers when provided). Treat every listed UUID as a possible storage key you must reconcile. - Track merges — Record which UUID pairs or sets you have already reconciled (for example in your own database), so repeat tool calls or retries do not double-apply logic.
- Stay idempotent — If the same comma-separated list appears again on a later request, your merge should be a no-op or safely upsert; Agentsyx may send the header on more than one call.
Agentsyx performs platform-side merge and bookkeeping; it does not rewrite rows inside your MCP server’s storage. Implement merge handling in your connector code paths that read HTTP headers.
Tool calls
Same fields as under params above: respond to name, read inputs from arguments, and optionally inspect params._meta for platform or host metadata.
Correlation
Use your own request id in logs. When x-ref-uuid or mcp-session-id is present, it can help align with Agentsyx support; there is no guarantee both are always set.
Org / project / deployment
Org, project, and deployment are handled by the platform before the request reaches your MCP server. They are not automatically added as extra JSON fields on the request unless you put them in tool arguments or use headers Agentsyx has documented for your integration.