Skip to main content
Glama
Sign In

briq

by cloud.briq
OverviewDiscussionsAdmin

Read a command started with async

briq_exec_result
Read-onlyIdempotent

Where a command started with briq_exec async stands: running, exited (with its exit code), timed_out, stopped or lost, with the last 64 KB of its stdout and stderr. Waits up to waitMs (30 s by default, 45 s at most) for it to finish before answering, so call it again while it runs. The whole output is in the briq: briq_files_get the path it names. To follow a stream of output (events, a log) without missing or repeating a line, pass offset (0 first): you get the output from that byte, and the offset to pass next; the wait then ends as soon as there is new output.

Input Schema

NameRequiredDescriptionDefault
briqYes
execYesexec id (ex_…), from briq_exec
offsetNoRead from this byte of the stream instead of its tail: 0 first, then the next offset each answer gives
streamNoThe stream offset reads; stdout by default
waitMsNoHow long to wait for it to finish, or with offset for new output; 30000 by default
maxBytesNoWith offset: the most to read in one call; 32768 by default

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / maxBytes
      Added value: +{
+  "description": "With offset: the most to read in one call; 32768 by default",
+  "maximum": 262144,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "description": "Read from this byte of the stream instead of its tail: 0 first, then the next offset each answer gives",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / stream
      Added value: +{
+  "description": "The stream offset reads; stdout by default",
+  "enum": [
+    "stdout",
+    "stderr"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / waitMs / description
      Previous value: -"How long to wait for it to finish; 30000 by default"New value: +"How long to wait for it to finish, or with offset for new output; 30000 by default"
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Adds substantial context beyond the readOnly/idempotent annotations: the default 30 s and max 45 s wait, the 64 KB stdout/stderr tail cap, and the fact that the wait ends early once new output exists when offset is used. Slight deduction only because the response shape (fields returned besides the tail and next offset) is left partly implicit.

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?

Three tight sentences that front-load the status answer before the wait and streaming mechanics. Dense but nearly every clause carries information; the 'The whole output is in the briq' clause is slightly telegraphic but still earns its place by routing to briq_files_get.

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?

There is no output schema, yet the description tells the agent what comes back (status, exit code, timestamp semantics, last 64 KB of both streams, next offset) and how to get the full output. Nothing essential is missing for correct invocation or interpretation.

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 already 83%, and the description adds real semantic depth for the tricky ones: offset starts at 0 and the next offset comes back in the answer, and waitMs doubles as a new-output wait when offset is set. stream and maxBytes are left to the schema, which is acceptable given the 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 specific verb and resource ('Where a command started with briq_exec async stands') and enumerates the exact status values it reports (running, exited with exit code, timed_out, stopped, lost). Clearly distinguishes itself from briq_exec (which starts the command) and briq_exec_stop.

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?

Explicitly says to call it again while the command runs, names briq_files_get as the route to the complete output rather than the 64 KB tail, and prescribes the offset protocol for following a stream without gaps or repeats. Only minor gap is no explicit mention of briq_exec_stop for termination.

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

All briq toolsInspect
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.

Resources