Loading ToolBench
Unified local Qwen3.8-27B Anser agent harness & MCP server: in-process Anser microkernel, structural AST surgery (@ast-grep/napi), bounded traceback condenser, 90-vector zero-trust sandboxed filesystem, closed-loop evolutionary optimization (.evo/lineage.json), vLLM + DFlash2 + KVarN @ 245K context, zero-turn OS wait @18021, and engine wedge detection.
Single tool 'qwen_coworker' has a comprehensive description (380+ chars) and detailed parameter schema with 10 parameters, all typed and described. However, output schema is not documented, the tool returns task results but the response structure is not formally specified. Parameter descriptions are generally good but lack some constraint details (e.g., timeout_ms minimum/maximum are stated in description but not in schema). Error handling guidance is minimal, no recovery hints for common failure modes. Tool naming is clear and verb-based. Overall: solid foundation with gaps in output documentation and error recovery patterns.
Primary autonomous execution coworker for local Qwen3.8-27B via Anser microkernel harness ($0 local text execution). Has full native access to Filesystem, Shell, and Git across Windows and WSL. Pure text-only model with Universal 245K context. Executes codebase exploration, refactoring, implementation, diagnostics, live web/docs research, and git operations. ORCHESTRATION RULES: - Single Logical Concern: Scope each prompt to ONE cohesive subsystem, architectural layer, or target AST slice. Do not bundle disparate subsystems or cross-cutting concerns into a single dispatch. - Full Objective Fulfillment: Do not instruct Qwen to limit its tool calls or artificially restrict its execution. Qwen operates autonomously with full tool depth once dispatched with a focused objective. - Session Lifecycle: Use persistent `session_id` across 2-3 focused turns, then roll to a fresh session_id (e.g. '<milestone>_stage2') when context accumulates. - Zero-Turn Execution Contract: Tasks completing within ~45s return results synchronously. Long-running tasks yield a `taskId` and a `wait_command`. Execute the `wait_command` immediately in your shell to block at $0 cost and wake on completion. Do not poll manually or execute parallel exploratory tools while waiting. - Reasoning Effort: optional `reasoning_effort` param (xhigh | medium | low) tunes per-dispatch thinking depth; omit to use the QWEN_REASONING_EFFORT env default (xhigh). SUPPORTED EXTENSIONS: - `uvx free-search-mcp` (Web search, documentation lookup, PDF/DOCX ingestion) - `npx -y @upstash/context7-mcp` (Live framework/library documentation) - `gh` CLI / `git` (Authenticated GitHub operations and atomic commits)
Output schema not documented. Tool description does not specify the structure of returned task results, completion status, or error responses. LLMs cannot plan downstream actions without knowing what fields to expect.
Error handling lacks recovery guidance. No description of what errors can occur (timeout, wedge, out-of-memory) or how the agent should respond. A raw error code gives the LLM nothing actionable.
Numeric parameter constraints not in schema. timeout_ms, higher_is_better, and other numeric params have constraints stated in descriptions (e.g., 'minimum 600,000ms') but not in JSON Schema min/max fields. LLMs cannot read description text for validation.
Enum constraints for reasoning_effort not enforced in schema. Description states 'Only the engine's supported tiers are accepted; invalid values are rejected' but the schema does not declare an enum. LLMs may pass unsupported values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
No pagination or result-limiting guidance. Tool can return unbounded task results and logs. No mention of max result size, truncation, or how to handle large outputs that blow context windows.