Inputs to downstream servers
Reference for the JSON-RPC body and HTTP headers on requests to your MCP server URL—the endpoint you configure on your connector in Agentsyx.
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 uses this slot for metadata (host- or platform-specific keys). Agentsyx may add entries here—for example a stable anonymous user key—so your handler can readparams._meta. Details: 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 for your downstream connector (the platform uses it to authenticate to your server). Treat the token as a secret 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 user records (e.g. anonymous) that Agentsyx has merged into the current authenticated user. See below—your downstream MCP server must react to this header. |
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
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 UUIDs (or by anonymous-era identifiers) so it lines up with the current authenticated user (using
x-a6-user-uuidand related headers when provided). - 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.