Built for machines

Your agent's new favorite tool

A hosted MCP server. A REST API. A CLI that speaks JSON. And flag files your agent can edit like any other file in the repo. Take whichever path fits — they all write the same git history.

Connect the MCP server Read the API docs

Meet it where it is

Wherever your agent already runs

Agents don't all live in the same place, and they don't all have the same reach. Pick the surface that matches where the work is happening.

In the terminal

Claude Code, Cursor, Codex

The agent writing the feature can read the flag that guards it — and check what production is actually serving before it touches a rollout. Sign in through the browser; no key to hand it.

MCP · git · qfgQuonfig + Claude Code

In Slack

Claude Tag

Your team asks about rollouts where they already discuss them. A shared service account means every answer — and every flip — is attributed to the bot, not to a person.

MCP · qf_sa_ keyQuonfig + Claude Tag

In CI

Pipelines and scripts

Gate a deploy on a flag's state, flip a kill switch from a runbook, or reconcile config as part of a release job. Plain HTTPS with a Bearer key and an OpenAPI 3.1 spec to generate against.

REST API v1REST API reference

Anywhere else

Any MCP client

The server is streamable HTTP at a public URL, and the tools are the same REST surface underneath: same permissions, same validation, same audit trail. Nothing is special-cased for one vendor.

mcp.quonfig.com/mcpMCP server docs

How it fits together

Four ways in, one git history

The CLI, the MCP server, and the flag files on disk aren't competing integrations — they're different hands on the same repo. Whichever one an agent uses, the result is a commit.

MCP server

Point Claude at your flags

One command, then sign in through your browser. No API key to paste, rotate, or leak — the session acts with your own Quonfig permissions.

Add it once

~ claude mcp add

$ claude mcp add --transport http quonfig \
    https://mcp.quonfig.com/mcp
Added HTTP MCP server quonfig

$ claude
> /mcp
  quonfig   connected   15 tools

Then it just knows

~ claude

> is checkout-v2 safe to remove? I want to delete the
  old branch in this file

  ⏺ quonfig - get_flag(checkout-v2)
  ⏺ quonfig - get_flag_history(checkout-v2)

  It's been 100% on in production for 6 weeks and
  staging matches. Nothing has changed it since
  Jun 24. Safe to remove — I'll strip the branch
  and open a PR that retires the flag too.

15 tools

13 reads, 2 writes

List and inspect flags, configs, and segments; read the git history behind any of them; and when it's time to change something, write it.

your permissions

Not a shared god key

Over Claude Code you sign in as yourself, so the agent can only do what you can. Protected environments stay protected.

same audit trail

A flip from Slack looks like any other

Writes land as commits in your workspace repo with an author and a diff. History responses mark bot changes with isServiceAccount.

Any MCP client works the same way — point it at the URL and pick an auth method.

Claude Tag

Flags where your team already talks about them

Give Claude in Slack a Quonfig service account and the channel can ask what production is serving — or change it — without anyone opening a dashboard.

Claude Tag acts as one shared identity for the channel, so it authenticates with a qf_sa_ service-account key. Every change it makes is attributed to that bot in your git history — not to whoever happened to mint the key.

Set up Quonfig + Claude Tag

No server required

Or skip the network entirely

An agent already sitting in your repo doesn't need an API to change a flag. The config is a file next to the code it guards.

JSON files

The open source path

Your agent already knows how to edit files. That's enough. Edit a JSON config, commit the change. Validation hooks ensure the structure is correct. No CLI, no key, no account.

git-workflow.sh

# Create a feature flag — no CLI needed
$ cat > feature-flags/checkout-v2.json << 'EOF'
{
  "key": "checkout-v2",
  "type": "feature_flag",
  "valueType": "bool",
  "default": {
    "rules": [{
      "criteria": [{ "operator": "ALWAYS_TRUE" }],
      "value": { "type": "bool", "value": false }
    }]
  }
}
EOF
$ git add feature-flags/checkout-v2.json
$ git commit -m "Create checkout-v2 feature flag"
$ git push
# Pre-receive hooks validate the JSON structure

qfg CLI

Structured, validated, scriptable

Every command returns JSON when piped, and qfg pull / qfg push keeps the local checkout and the hosted workspace in sync.

qfg-cli

# Create a flag, default off
$ qfg create checkout-v2 --type boolean-flag --value=false
{
  "data": {
    "key": "checkout-v2",
    "path": "feature-flags/checkout-v2.json",
    "valueType": "bool"
  },
  "meta": { "action": "created" }
}
# Roll it out to 20% of production
$ qfg set-rollout checkout-v2 --environment production --true-percent 20
{
  "data": { "key": "checkout-v2", "truePercent": 20 },
  "meta": { "action": "updated", "environment": "production" }
}

Structured output

JSON your agent can actually parse

No more regex. No more table-scraping. Every response — CLI, REST, or MCP — is a typed envelope with data and metadata.

Typical CLI output

other-tool

NAME           TYPE    ENV         VALUE
checkout-v2    bool    production  true
new-pricing    string  staging     $39
dark-mode      bool    production  false
api-limits     int     staging     1000
onboarding     bool    production  true

Quonfig output

qfg list --json

{
  "data": [
    { "key": "checkout-v2", "valueType": "bool", "value": true },
    { "key": "new-pricing", "valueType": "string", "value": "$39" },
    { "key": "dark-mode", "valueType": "bool", "value": false },
    { "key": "api-limits", "valueType": "int", "value": 1000 },
    { "key": "onboarding", "valueType": "bool", "value": true }
  ],
  "meta": { "count": 5, "environment": "production" }
}

Preview every change before it ships

Because config is just JSON files in git, every change the agent makes is a diff you can read before it lands. The agent edits the config, opens a pull request, and the exact before/after is right there in the review — no opaque mutation, no guessing what changed.

And when an agent writes through MCP or the API instead, you still get the commit: same author trail, same diff, same revert. An agent can't make a change that isn't reviewable after the fact.

review-the-diff.sh

# The agent edits the JSON, then shows the diff before committing
$ git diff feature-flags/checkout-v2.json
diff --git a/feature-flags/checkout-v2.json
--- a/feature-flags/checkout-v2.json
+++ b/feature-flags/checkout-v2.json
@@ rules ...
-          "value": { "type": "bool", "value": false }
+          "value": { "type": "bool", "value": true }
# Exact before/after — reviewable like any code change
$ git commit -am "Enable checkout-v2 in production"
$ git push   # or open a PR for a human to approve the diff
# Pre-receive hooks validate the JSON structure

Self-describing

Your agent never has to guess

MCP tools carry their own schemas, the REST surface publishes an OpenAPI 3.1 spec, and every CLI command describes itself. Discovery happens at runtime.

Discover available operators

qfg schema operators

{
  "data": [
    { "name": "ALWAYS_TRUE", "description": "Matches all contexts" },
    { "name": "PROP_IS_ONE_OF", "description": "Property in list" },
    { "name": "IN_SEG", "description": "In segment" },
    { "name": "IN_INT_RANGE", "description": "Integer in range" },
    { "name": "PROP_ENDS_WITH_ONE_OF", "description": "Property ends with" },
    { "name": "HIERARCHICAL_MATCH", "description": "Namespace match" }
  ]
}

Generate a typed client

openapi.json

# The published contract — generate a client, don't hand-roll one
$ curl https://api.quonfig.com/v1/openapi.json -o quonfig.json
$ npx @hey-api/openapi-ts -i quonfig.json -o src/quonfig
# Check which identity a key acts as before you script against it
$ curl https://api.quonfig.com/v1/whoami \
    -H "Authorization: Bearer $QUONFIG_API_KEY"
{
  "workspaceId": "01J...",
  "principal": { "type": "service_account", "name": "deploy-bot" }
}

Agent context file

Ship a .qf/agent-context.md in your repo. Your agent auto-discovers it and follows the invariants, workflows, and guardrails you define.

Encode your team's policies as instructions your agent actually reads. No dashboards to configure. No RBAC policies to maintain. Just a markdown file in version control.

.qf/agent-context.md

# Quonfig Agent Context
## Invariants
- Open a PR on the JSON diff before changing a production flag
- Never delete a flag without checking it's no longer read in code
- Check current prod state over MCP before proposing a rollout change
## Common Workflows
- Create flag: qfg create <key> --type boolean-flag --value=false
- Roll out: qfg set-rollout <key> --environment production --true-percent 20
- Inspect a flag: qfg get <key> --environment production
- Complex targeting: qfg pull, edit the JSON, git push
## Guardrails
- Production changes go through a reviewable git diff first
- Retire finished flags: qfg cleanup list
- Operator reference: qfg config-schema

Give your agents real tools

Everything an agent can do, a human can do in the UI — and every change lands in the same git history either way. Agent-first doesn't mean agent-only.

MCP serverThe URL, the 15 tools, and both auth methods REST API v1Endpoints, keys, and the OpenAPI spec Quonfig + Claude CodeOne command, then browser sign-in Quonfig + Claude TagService accounts for Claude in Slack