Skip to main content
Glama
Sign In

briq

by cloud.briq
OverviewDiscussionsAdmin

Upgrade a home

briq_upgrade
DestructiveIdempotent

Upgrade a T3 home in place to the release from briq_upgrade_status. Finish work first. Returns a durable receipt immediately. Reuse the same idempotency UUID after an uncertain response. A legacy home requires explicit idle-maintenance acknowledgement. When commandInterruptionRequired is true, pass interruptUnconfirmedCommands: true only after explicit consent to interrupt unconfirmed descendants. Active commands still block.

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>",
      "targetRelease": "<targetRelease>",
      "idempotencyKey": "<idempotencyKey>"
    },
    "name": "briq_upgrade"
  }
}

Input Schema

NameRequiredDescriptionDefault
briqYes
targetReleaseYes
idempotencyKeyYes
interruptUnconfirmedCommandsNo
legacyMaintenanceAcknowledgedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, and the description adds real context beyond them: a durable receipt is returned immediately, the idempotency UUID must be reused after an uncertain response, and unconfirmed descendants are only interrupted with consent. It does not explain whether an upgrade is reversible or how partial failure is reported, which keeps it short of a 5.

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 action and then ordered by precondition, return behavior, retry semantics, and consent gates, with no filler. Two separate sentences ('Finish work first' and 'Active commands still block') state closely related blocking conditions, which is mildly redundant but arguably clarifying.

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

Completeness4/5

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

For a destructive, idempotent, five-parameter mutation with no output schema, the description covers preconditions, the receipt return, retry safety, and consent gates well. It stops short of describing failure/rollback behavior or what the receipt contains, which an agent managing an upgrade might want.

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 description coverage is 0%, so the description must carry parameter meaning, and it does address all five: the home, the release digest sourced from briq_upgrade_status, idempotency-key reuse, the legacy acknowledgement, and the consent condition for interruptUnconfirmedCommands. It omits format/pattern details (the bq_ id shape and sha256: digest form) that remain only in the schema.

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?

States a specific verb and resource ('Upgrade a T3 home in place') and pins the target value to the sibling tool briq_upgrade_status, so the agent can distinguish this from briq_up, briq_run, or briq_status without opening schemas. The scope qualifier 'T3' further narrows applicability.

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?

Explicit preconditions are given: finish work first, active commands block, and legacy homes need an idle-maintenance acknowledgement. It also names briq_upgrade_status as the source of the target release and gates the interrupt flag behind explicit consent, leaving little to inference.

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
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.

Resources