opencode-workbench

Remove one Workbench component

remove_component

DestructiveIdempotent

Uninstall one OpenCode Workbench component by id from a local or SSH target; previews changes unless confirm is true, and reports absent or manual when not removable.

Instructions

Uninstall one Workbench component by id from a target — the inverse of install_component — for a bounded, documented subset with an automated uninstall (e.g. opencode, pnpm, npm-mcps, skills, docker-containers); component must be an id from describe_workbench. Idempotent: an already-absent component reports absent; a component with no automated uninstall (system packages such as git/curl/node) reports manual. Destructive and consent-gated: without confirm:true it returns a preview and changes nothing, and it deletes only that component's files — never opencode.json or the profile repo. Parameter semantics: workspace sets the profile path some removals need; dryRun reports without changing. Use it to tear down one component; for several, call it per id.

Input Schema

TableJSON Schema

Name	Required	Description
`dryRun`	No	Report the action without changing anything.
`target`	Yes	The machine to operate on: this host (local) or a remote host over SSH (ssh).
`confirm`	No	Set true to actually remove. When absent, the call returns a preview and makes no changes.
`component`	Yes	Component id from describe_workbench.
`workspace`	No	Profile repo directory (used by components whose removal needs it).

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Component id acted on.
`code`	Yes	Exit code of the action.
`action`	Yes	What happened: removed, updated, already absent, or manual (no automated uninstall).
`output`	Yes	Captured output (truncated).
`target`	Yes	Label of the target.
`requiresConfirmation`	No	True when the call returned a preview without acting; re-call with confirm:true.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv4.0.1Oct 7, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the destructive/idempotent annotations it discloses consent gating (no `confirm:true` means preview only, nothing changes), idempotent outcomes (`absent` vs `manual` for non-automated system packages), and the exact deletion boundary (never `opencode.json` or the profile repo). This is precisely the extra context annotations cannot carry.

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?

Dense but well front-loaded: purpose, scope, then behavior, then parameter notes, then the multi-id routing rule. Length is justified by the tool's complexity, though `dryRun` and `confirm` are effectively restated from the schema, which is mild redundancy.

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?

An output schema exists so return values need no explanation, yet the description still covers the enum-like outcomes an agent must interpret (`absent`, `manual`, preview). Nothing needed to call or interpret this destructive tool correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents target/confirm/dryRun/component/workspace, and the description largely restates them. It adds only a small increment (that `workspace` supplies the profile path needed by some removals). Baseline 3 applies when the schema does the heavy lifting.

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 ('Uninstall one Workbench component by id from a target') and explicitly positions itself as the inverse of install_component, letting an agent separate it from siblings without opening any schema. It also bounds the scope to the documented subset with automated uninstall.

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

Usage Guidelines4/5

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

Gives clear routing: 'Use it to tear down one component; for several, call it per id,' plus the precondition that the id comes from describe_workbench. It does not name when a different sibling (e.g. update_component) is the better choice, so it falls short of full when/when-not guidance.

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

Deploy Server