briq

Move a briq into or out of a stack

briq_move

Idempotent

Put a briq in a stack, or take it out. Briqs of one stack reach each other by name; a briq in no stack reaches none, so a briq whose env uses {{briq:NAME}} cannot be taken out (refused). Example: { briq: "bq_…", stack: "shop" } (a new name makes the stack), or { briq: "bq_…", stack: null } to take it out. To group briqs made apart: move the first into a new stack (free), then create the next ones in it (briq_run with stack). A briq alone that joins a new stack, or leaves one, moves in place: no restart. A running briq that joins a stack that already has briqs restarts: its processes start over and its private IP changes, so finish or save work first (restarted: true). If the stack's briqs run on another host the move is refused: make the briq again in the stack. The briq keeps its disk, name and URLs. Briqs left in the old stack no longer reach it. Returns once it lands (up to 30 s); moving means it is still on its way.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "briq": "<briq>",
      "stack": "<stack>"
    },
    "name": "briq_move"
  }
}

Input Schema

Name	Required	Description	Default
`briq`	Yes
`stack`	Yes	The stack to move it into (a name; a new name makes it), or null to take it out

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Substantially exceeds the annotations (readOnly=false, idempotent=true, destructive=false) by disclosing restart semantics, that a restarted briq's processes start over and its private IP changes, that disk/name/URLs are preserved, that old-stack peers lose reachability, the 30 s wait and the `moving` / `restarted: true` signals. These are exactly the operational consequences an agent needs before mutating a running workload and are not derivable from the annotations.

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 purpose and the two call shapes, then consequences and refusals; every sentence carries operational information. Some sentences are dense and multi-clause (the cross-host refusal and the reachability note), which costs a little readability but no content is filler.

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, and the description nonetheless explains the return timing and status values (`moving`, `restarted: true`). For a two-parameter mutation tool with restart side effects, all decision-relevant behavior — refusals, cost, side effects, data preservation — is present.

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?

With 50% schema coverage (only `stack` is described), the description compensates by explaining that a new name creates the stack and null removes the briq, and it supplies worked examples for both call shapes. It does not explain the `briq` identifier's format beyond the example, but the schema pattern covers that.

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 pair ("Put a briq in a stack, or take it out") that is unmistakable and clearly distinct from siblings like briq_run, briq_destroy, or briq_start. The bidirectional scope (into / out of) is stated immediately, so an agent can discriminate the tool without opening the schema.

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 when-to-use guidance ("To group briqs made apart: move the first into a new stack (free), then create the next ones in it (briq_run with stack)"), naming the sibling and the ordering. It also documents when-not-to-use: removal is refused for a briq whose env uses `{{briq:NAME}}`, and moves are refused when the stack's briqs live on another host — with the prescribed alternative (recreate the briq in the stack).

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.