Skip to main content
POST
Write a secret env value and its manifest !ENV marker together, then reload

Authorizations

x-api-key
string
header
required

Body

application/json

The combined env+manifest secret op body (POST /api/mcp-config/secret-env).

value is the raw secret pasted by the operator. The env KEY it is stored under is EITHER an explicit key OR generated from key_hint — exactly one is given ({value, key | key_hint, manifest_pointer}). The server writes value to the env store under that key (marked secret) and writes an !ENV ${KEY} MARKER at manifest_pointer — so the secret lives only in the env store and the manifest carries a placeholder. An explicit key that collides with an existing stored key holding a DIFFERENT value is refused with a loud 400 naming the key (never a silent overwrite of a live secret). manifest_pointer is a slash-delimited, no-leading-slash path (e.g. mcp/0/config/headers/Authorization) whose HEAD segment MUST be mcp (the same mcp-only authority set_mcp_config holds). The generated key is NOT returned.

manifest_pointer
string
required
value
string
required
key
string | null
key_hint
string | null

Response

Success.

data
ApplyResponse · object
required

The standard mutation-op response: this worker's local reload result merged with the fleet fan-out summary.

env_keys is the count of env keys the reload loaded. recycle is the fleet recycle roll the change ran — null when it had no worker to visit: every worker's reload confirmed no recycle-class key moved off its bound value, or the only ones naming one were refused at their epoch build or are the writer whose own restart cannot follow as its exit. awaiting_respawn is the operation's verdict: the workers still awaiting a respawn after it (name + keys) — when the roll converged and this worker recycles itself, only the workers whose reload was refused at their epoch build: the stored config did not build on them and a restart may fail the same way, so the roll leaves them running and lists them; a worker the roll did not reach keeps its keys. roll_deferred is true when the roll is not judged in this reply: roll_deferred_to then names the worker that carries it out after the reply (recycle is null and awaiting_respawn empty), and is null otherwise. span_release_error is null when the config store released its exclusive write span after the persist; otherwise the store's error — the change landed and the reload, broadcast and roll reported here still ran, but the store may still hold its write span until the writer process exits, so a later write can block or be refused until then.