briq

Run a command in a briq

briq_exec

Destructive

Execute a command inside a running briq and return stdout, stderr and the exit code, for up to 60 s. Use for migrations, seeding, health checks, the commands of a sandbox briq (scripts, tests, builds), or anything you would run with docker exec. Anything that can take longer (a build, a test suite, a data load): pass async: true, which starts it and answers at once with an exec id; then briq_exec_result reads it (it waits 30 s a call, up to 45 with waitMs) and briq_exec_stop stops it. Async needs sh and setsid in the image, as most have. Keep the command under about 16 KB: send bigger input as stdin. A sleeping briq is woken first, with the sleeping briqs of its stack, so the call is slower; on a stopped one, the error says why.

Input Schema

Name	Required	Description
`cmd`	Yes	argv, run without a shell: ["psql", "-c", "select 1"], not ["psql -c 'select 1'"]. For pipes, globs, && or $VARS: ["sh", "-c", "…"]
`env`	No	Variables for this command only, over the briq's own: { NAME: value }. Kept off its command line, and out of status and the audit log
`briq`	Yes	briq id (bq_…)
`async`	No	Start it and answer at once with an exec id, for a command that can take over a minute; read it with briq_exec_result. A running command keeps its stack awake
`stdin`	No	Text fed to the command's standard input
`clearEnv`	No	Start it from an empty environment: only the briq's PATH, HOME and LANG, then env. So a variable of the briq (an API key) does not reach it
`stdinOpen`	No	With async: keep its stdin open, to write to while it runs with briq_exec_input (a follow-up message, an approval) until eof. Not with stdin
`timeoutMs`	No	Without async: 60000 by default and at most. With async: when to stop it, 3600000 (1 h) by default, 86400000 (24 h) at most

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 27, 2026

addedInput schema / properties / clearEnv

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "const": "true",
+      "type": "string"
+    },
+    {
+      "const": "false",
+      "type": "string"
+    }
+  ],
+  "description": "Start it from an empty environment: only the briq's PATH, HOME and LANG, then env. So a variable of the briq (an API key) does not reach it"
+}

addedInput schema / properties / env

Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "description": "Variables for this command only, over the briq's own: { NAME: value }. Kept off its command line, and out of status and the audit log",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

addedInput schema / properties / stdinOpen

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "const": "true",
+      "type": "string"
+    },
+    {
+      "const": "false",
+      "type": "string"
+    }
+  ],
+  "description": "With async: keep its stdin open, to write to while it runs with briq_exec_input (a follow-up message, an approval) until eof. Not with stdin"
+}

First observedOct 27, 2026

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructive/openWorld/non-idempotent, and the description adds substantial context beyond that: the ~60 s sync ceiling, the ~16 KB command-size limit with `stdin` as the escape hatch, async's dependency on sh and setsid in the image, that async keeps the stack awake, and that a sleeping briq (and its stack) is woken first, making the call slower. It stops short of describing permission/auth requirements or what the returned payload looks like beyond the three streams.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core contract and return values, then the timeout/async path, then edge constraints (size limit, sleeping/stopped briqs). Nearly every clause carries information, though the async sentence packs three tool names and two wait durations into one dense run that takes a re-read.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still states what comes back (stdout, stderr, exit code) and covers the operational hazards an agent must plan for: sync duration cap, size cap, waking latency, and stopped-briq failure mode. Nothing essential to a correct first call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description still adds guidance the schema only partly carries, notably the command-size threshold that motivates `stdin` and the concrete selection criteria for `async` beyond the one-line schema text. The remaining parameters (env, clearEnv, stdinOpen, timeoutMs) are left entirely to the schema, which is acceptable given full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a concrete verb+resource+return contract: execute a command inside a running briq, returning stdout, stderr and exit code. It explicitly disambiguates from the sibling family by naming briq_exec_result and briq_exec_stop for the async path, so an agent can route correctly without reading other schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit use cases (migrations, seeding, health checks, sandbox scripts/tests/builds, docker exec equivalents) and an explicit exclusion rule: anything that can take longer must use `async: true`, with the follow-up tools named. The condition that selects each alternative is stated, not inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All briq tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Run a command in a briq

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources