opencode-workbench
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| describe_workbenchA | Describe this MCP server from its bundled profile without contacting any target or making a network call: repository URL, the default component set, components grouped by tier (required/core/optional), and optional MCP add-ons. It takes no parameters, is always safe, and returns instantly. Use it first to resolve a component id for install_component/remove_component/update_component or to see available add-ons; use inspect_target for a machine's live state. |
| inspect_targetA | Probe one Linux machine — this host ( |
| plan_cloneA | Return a read-only plan for a target: compare it against the Workbench profile and list each component as |
| apply_cloneA | Apply the Workbench profile to a target: clone the repo and install missing components (OpenCode CLI, Node/pnpm, MCP servers, skills, plugins, optional Docker). It OVERWRITES |
| verify_cloneA | Re-check a target after a clone: return a per-component |
| install_componentA | Install a single Workbench component by id (e.g. |
| remove_componentA | 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. |
| update_componentA | Update one Workbench component in place by id: re-run its install script to fetch the current version (e.g. |
| list_required_credentialsA | List the credentials the profile references, which the target already provides, and how to acquire each missing one. Value-blind: it reads only whether each env var is set — no values, no network, no writes — via one read-only probe. Parameter semantics: |
| run_auth_flowA | Return the acquisition plan for one credential on a target: the provider URL, the exact non-interactive command when one exists (e.g. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Most tools have clearly distinct purposes, and the descriptions explicitly cross-reference each other (inspect_target for live state, plan_clone for a diff plan, verify_clone for post-clone re-check). The three read-only probe tools (inspect_target, plan_clone, verify_clone) overlap somewhat and require careful reading to separate, but the descriptions do enough to guide selection.
Every tool follows a consistent snake_case verb_noun pattern: verify_clone, describe_workbench, inspect_target, plan_clone, apply_clone, install_component, remove_component, update_component, list_required_credentials, run_auth_flow. The component lifecycle (install/remove/update) is especially clean and predictable.
Ten tools is well-scoped for a workbench provisioning/profiling server. Each tool earns its place, covering the full flow from describe and inspect through plan, apply, verify, per-component management, and credentials.
The surface covers the full lifecycle: describe, inspect, plan, apply, verify, plus per-component install/remove/update and credential discovery/auth guidance. Coverage is strong; the only minor gap is the deliberate absence of any secret-value handling, which is an intentional design constraint rather than an oversight.