Getting started

briq exposes one MCP server, https://api.briq.cloud/mcp, over Streamable HTTP with a Bearer API key. Clients that do not support remote MCP yet can use the stdio shim npx @briq/mcp, which proxies to the same endpoint using BRIQ_API_KEY.

1. Create an API key

Sign in at briq.cloud/app. A personal team is created for you.
Go to API keys, click Create key, give it a name.
Copy the key once. It is stored hashed; we cannot show it again.

The default policy is deliberately small: 5 concurrent briqs, €10 per day, sizes nano and small, images from docker.io and ghcr.io, TTL up to 24 hours. See Keys and policy to widen or narrow it.

Export it in the shell you run your agent from:

export BRIQ_API_KEY=bq_live_…

2. Connect your client

claude mcp add briq --transport http https://api.briq.cloud/mcp \
  --header "Authorization: Bearer $BRIQ_API_KEY"

Add --scope project to commit the server to .mcp.json for your team, or run briq mcp install claude from the CLI to do the same.

Claude Desktop uses stdio servers. Add the shim to claude_desktop_config.json:

claude_desktop_config.json

{
  "mcpServers": {
    "briq": {
      "command": "npx",
      "args": ["-y", "@briq/mcp"],
      "env": { "BRIQ_API_KEY": "bq_live_…" }
    }
  }
}

.cursor/mcp.json

{
  "mcpServers": {
    "briq": {
      "url": "https://api.briq.cloud/mcp",
      "headers": { "Authorization": "Bearer ${env:BRIQ_API_KEY}" }
    }
  }
}

Or briq mcp install cursor.

~/.codex/config.toml

[mcp_servers.briq]
url = "https://api.briq.cloud/mcp"
bearer_token_env_var = "BRIQ_API_KEY"

Or briq mcp install codex.

opencode.json

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "briq": {
      "type": "remote",
      "url": "https://api.briq.cloud/mcp",
      "headers": { "Authorization": "Bearer {env:BRIQ_API_KEY}" },
      "enabled": true
    }
  }
}

~/.gemini/settings.json

{
  "mcpServers": {
    "briq": {
      "httpUrl": "https://api.briq.cloud/mcp",
      "headers": { "Authorization": "Bearer $BRIQ_API_KEY" }
    }
  }
}

Once connected, the client lists 15 briq_* tools and a briq_getting_started prompt. You do not need to write any instructions for the model: tool descriptions are written for models and tell it to prefer recipes, reuse a stack, and always destroy what it created.

3. Your first briq

Ask your agent something that needs a real service:

Spin up a Postgres, run pnpm prisma migrate deploy against it, and tell me if the migrations are clean.

A typical run:

briq_run({ recipe: "postgres", params: { version: "16" }, wait: true })
→ running bq_7kq2m9x1p4ab · postgres:16 · small · cost so far €0.01 · stops at 18:42
  DATABASE_URL=postgres://postgres:••••••••@db.s1.internal:5432/app

$ pnpm prisma migrate deploy
All migrations have been successfully applied.

briq_destroy({ briq: "bq_7kq2m9x1p4ab" })
→ destroyed bq_7kq2m9x1p4ab · ran 41s · cost so far €0.01 · stops at 18:42

Three things to notice:

wait: true blocks until the recipe's healthcheck passes (pg_isready here), so the agent never talks to a database that is still booting.
Credentials come back as recipe outputs, generated per run. POSTGRES_PASSWORD is a write-only secret: it appears in the output once and is masked in status, logs and audit.
Even if the agent forgets briq_destroy, the briq stops at stopsAt (default TTL 60 minutes).

4. Watch it from the dashboard

briq.cloud/app shows running briqs, spend today, and the audit log: one row per tool call with the key, action, target, duration and cost delta. From there you can stop, extend or destroy anything your agent started.

Without an agent

The same API is available from the CLI and the TypeScript SDK:

briq run postgres
briq exec bq_7kq2m9x1p4ab -- psql -c 'select 1'
briq rm bq_7kq2m9x1p4ab