Every way to manage and read flags: console, MCP tools and REST.
With an MCP key for your dev environment, an AI assistant can manage the organization's flags directly, and a tenant's changes through the tenant tools.
| Tool | Does |
|---|
list_feature_flags | The organization's flags with the plan's limits. |
describe_feature_flag | One flag in full. |
create_feature_flag | Creates a flag. A boolean flag needs only key and name and starts off. Other kinds need variations, off_variation and fallthrough. |
update_feature_flag | Changes a flag (send version to refuse if someone else edited it). The key and kind cannot change. |
delete_feature_flag | Deletes a flag (assets fall back to their own defaults). Consider archiving instead. |
list_tenant_feature_flags | Flags as one tenant gets them, with what that tenant changed. Needs tenantCode. |
set_tenant_feature_flag | Changes parts of a flag for one tenant; null returns a part to the organization's value. |
clear_tenant_feature_flag_override | Removes a tenant's changes for a flag. |
The tools explain the flag model and how Logic Blocks, Glyphs and agents read flags in their own descriptions, so an assistant can build a feature and wire it up in one go. get_platform_capabilities returns the full guide as featureFlagsGuide.
REST: reading
| Method and path | Who | Does |
|---|
POST /app/{orgCode}/featureflags/evaluate | Any signed-in user | The caller's flags. Optional body { keys, context: { attributes } }. |
GET /app/{orgCode}/featureflags/evaluate?keys=a,b | Any signed-in user, even read-only | The same without attributes. |
REST: a tenant's flags (tenant admin)
| Method and path | Does |
|---|
GET /app/{orgCode}/tenant/featureflags[?key=&as=&attr.x=] | List, or get one (optionally test as a user). |
PUT or POST /app/{orgCode}/tenant/featureflags | Set parts for this tenant. Body { key, enabled?, off_variation?, fallthrough?, rules?, targets?, schedule?, window?, version? }. |
DELETE /app/{orgCode}/tenant/featureflags?key= | Clear this tenant's changes. |
The organization's definition
{
"key": "checkout-button",
"name": "Checkout button colour",
"kind": "string",
"variations": [
{ "id": "blue", "name": "Blue", "value": "#1d4ed8" },
{ "id": "green", "name": "Green", "value": "#16a34a" }
],
"enabled": true,
"off_variation": "blue",
"fallthrough": { "rollout": [ { "variation": "blue", "weight": 50 }, { "variation": "green", "weight": 50 } ] },
"targets": [ { "variation": "green", "user_ids": ["u_1042"] } ],
"rules": [ { "clauses": [ { "attribute": "plan", "op": "in", "values": ["pro"] } ], "serve": { "variation": "green" } } ],
"schedule": [ { "at": "2030-11-24T09:00:00Z", "patch": { "enabled": true } } ],
"window": { "from": null, "until": "2030-12-02T00:00:00Z" },
"overridable": true
}
Errors you can expect
| Status | When |
|---|
400 | Invalid input: bad key, a value that does not match the kind, weights that do not add up to 100, an unknown value id, a schedule time in the past. |
402 | Your plan's flag or scheduled-change limit is reached (the message says what to upgrade). |
403 | A tenant admin is required, the flag is locked by the organization, or you are on production (definitions change in dev; only the on/off switch works in production). |
404 | Unknown flag or section. |
409 | Someone else changed the flag — reload and try again. |