Loading ToolBench
A Windows shell / tool bridge designed for LLM agents (MCP / CLI / Web API).
Three tools with clear, detailed descriptions (194 - 250 chars each) and explicit input schemas. Tool names follow verb_noun pattern (wlb_tool_*). However, schema completeness varies: wlb_tool_list has empty input ({}), wlb_tool_show has one required string param, wlb_tool_run has two params but lacks type constraints (enums, ranges). Output schemas are not formally documented in the visible code, only described in prose. Error handling guidance is present in descriptions but not structured. No tool annotations (readOnlyHint/destructiveHint) visible in schema definitions.
List every tool declared in ``workspace/wlb-tools.toml``. Each tool entry includes name, description, interpreter, declared args, and timeout. To see the full spec (including the command template and regex patterns), call ``wlb_tool_show`` for a specific name.
Run a declared tool on the Windows host. The tool's command template is formatted with ``args``, prefixed with a workdir-changing wrapper if the spec sets one, then run through the configured interpreter (cmd / powershell / raw). The full output is saved under ``workspace/hosts/<host>/tools/<name>/<ts>.log``. Progress notifications (M3.10): When the calling MCP client supplied a ``progressToken`` (FastMCP exposes it via ``ctx.report_progress``), wlb_tool_run emits standard ``notifications/progress`` messages whenever the tool's ``progress_re`` matches a fresh percentage in the live output. Failure-pattern hits surface as ``ctx.warning``; a "still running, N lines so far" tick every 50 lines surfaces as ``ctx.info``. Final structured result is the same whether or not progress was requested.
Return the full declared spec for one tool. Use this before invoking ``wlb_tool_run`` to learn the required args and command template. The spec is read-only — wlb won't modify ``wlb-tools.toml`` from here.
wlb_tool_run 'args' parameter lacks type constraints. Description mentions forbidden characters (newlines, NULs, shell metacharacters) but no enum, pattern, or minLength/maxLength in schema. LLMs cannot validate input before calling.
Output schemas not formally documented. Tool descriptions mention return fields (exit_code, stdout_tail, success, log_path, etc.) but no JSON Schema definition visible for ToolRunOutput or response structure. LLMs cannot plan downstream tool calls without knowing response shape.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) in schema. wlb_tool_list and wlb_tool_show are read-only; wlb_tool_run is destructive (WRITE). Annotations help LLMs reason about safety and retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
wlb_tool_list has empty input schema ({}). While correct for a no-argument tool, no description explains what it returns or when to call it. Baseline: discovery tools should explain structure revealed.
Error handling is prose-only. Descriptions mention 'failure-pattern hits surface as ctx.warning' but no structured error response format (error codes, recovery guidance, retryable classification) visible in schema or code.