opencode-workbench

Inspect a Linux target

inspect_target

Read-onlyIdempotent

Probe a local or SSH Linux host to report OS, kernel, tooling, and credential names before cloning. Read-only, installs nothing, and runs one shell command per target.

Instructions

Probe one Linux machine — this host (local) or a remote host over SSH (ssh) — and report its OS, kernel, architecture, package manager, Node/npm, OpenCode, Docker, and per-tool detection flags, plus the names (never values) of credentials present. Read-only: it runs one shell probe as the target user (over SSH when mode:ssh), installs nothing, writes nothing, contacts no external service, and can take a few seconds per hop. Parameter semantics: target.mode selects local vs ssh (default local); target.host is required only for ssh; target.user defaults to the ssh config/current user; target.cwd sets the directory for relative checks; target.port/identityFile pass straight to ssh. Use it to see what a clone would touch, then plan_clone to turn that into an ordered plan and apply_clone to perform it.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`target`	Yes	The machine to operate on: this host (local) or a remote host over SSH (ssh).

Output Schema

TableJSON Schema

Name	Required	Description
`has`	Yes	Detection flags for git, curl, node, npm, corepack, pnpm, docker, uv, gh, opencode, sudo.
`arch`	No	CPU architecture (e.g. x86_64, aarch64).
`home`	Yes	Home directory on the target.
`osId`	No	OS identifier (e.g. ubuntu, debian, rhel).
`user`	Yes	Detected user on the target.
`kernel`	No	Kernel name and release.
`osName`	No	Human-readable OS name.
`configDir`	Yes	OpenCode config directory on the target.
`osVersion`	No	OS version string.
`envPresent`	No	Space-separated names of credentials present on the target (values are never read).
`npmModules`	No	npm global modules directory.
`nodeVersion`	No	Installed Node.js version, if any.
`opencodeBin`	No	Path to the opencode binary, if installed.
`dockerRunning`	No	Whether the Docker daemon is reachable.
`packageManager`	No	Detected package manager (apt-get, dnf, yum, apk, pacman, zypper, or none).
`workspaceDefault`	Yes	Default directory where the profile repo will be cloned.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv4.0.1Oct 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint/openWorldHint/idempotentHint annotations by disclosing the exact execution model (one shell probe as the target user, over SSH in ssh mode), the side-effect profile (installs nothing, writes nothing, no external service), latency (a few seconds per hop), and a privacy guarantee (credential names, never values).

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 before behavior, usage, and parameters, and every sentence carries information. It is a dense single paragraph that could be broken up, but there is little redundancy to cut.

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 not be re-explained, and the description still covers scope, side effects, latency, parameter behavior, and the follow-on workflow. Nothing needed to call this tool correctly is missing.

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 100%, so the baseline is 3; the description still adds value by explaining mode default, that host is required only for ssh, and that port/identityFile pass straight through to ssh. Minor nit: it calls mode default `local` while the schema marks it required, a small inconsistency rather than a contradiction.

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 ('probe one Linux machine') and enumerates exactly what is reported (OS, kernel, architecture, package manager, Node/npm, OpenCode, Docker, detection flags, credential names). This is clearly distinguishable from siblings like describe_workbench or verify_clone.

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 routes the agent: use inspect_target to see what a clone would touch, then plan_clone for an ordered plan, then apply_clone to perform it. The when-to-use and the named alternatives are both present, leaving nothing to inference.

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

Deploy Server