Loading ToolBench
HTTP-based server for guided brownfield onboarding and context-layout discovery in the Context Engineering Protocol. Provides a web UI for repository analysis, decision staging, and layout initialization with session-based authentication.
This server exposes 19 tools via HTTP but lacks critical definition infrastructure. Most tools (1-12) have NO visible input schemas in the source code, only brief descriptions. Tools 13-19 show partial schemas in the evaluation data, but the actual MCP tool registration mechanism is not visible in the provided code. The server appears to be a custom HTTP implementation, not a standard MCP server with proper tool registration. Naming is inconsistent (verb_noun for some, but 'build_boxes', 'compute_state', 'run_discover' lack clarity). Descriptions are present but generic (10-50 chars for most), well below the 50-200 char LLM-optimized baseline. No error handling guidance, no output schemas documented, no parameter validation rules visible. The codebase shows a Flask-like HTTP handler but no MCP protocol implementation (no tool definitions, no schema validation, no structured responses).
Commits confirmed decision changes to the layout
Builds the four-box view model for the wizard status display
Computes the four-state router state for the wizard frontend, including workspace_root_current and workspace_root_offer_eligible
Discovers onboarding slots and validates their existence. Checks file/directory presence and optionally globs How-L2 artifacts (CODING-STANDARDS.md, TESTING-GUIDELINES.md, interfaces/*.md, CONTEXT.md).
Finds and renders one CEP documentation file to HTML on request
Deterministic, zero-LLM markdown structural indexer. Builds a searchable index of markdown documents with heading detection, cross-reference extraction, and profile-based clause ID parsing.
Tools 1-12 have NO visible input schemas in source code. Only brief descriptions provided. Cannot verify parameter types, constraints, or required fields.
Descriptions are generic and under 50 chars for most tools (e.g., 'Builds the four-box view model', 'Renders markdown documentation'). LLM-optimized descriptions should be 50-200 chars and answer WHAT, WHEN, and WHY. Current descriptions lack context for tool selection.
No output schemas documented anywhere. LLMs cannot plan downstream calls or extract required fields. Tools like 'query' and 'discover' return results but structure is undocumented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 28 | 2026-07-28+ | v2 |
Directory browsing for the wizard picker interface
Lists the closed set of CEP's own documentation available to render
Splices marked content blocks into target files. Creates file if missing, replaces block if markers present, or appends block if markers absent. Idempotent operation.
Dry-run preview of workspace root initialization with zero disk writes
Queries a markdown index for terms with relevance ranking
Batch query a markdown index with multiple search queries
Reads and parses decision-line state from the layout source
Renders markdown documentation to HTML
Runs in-process (re-)generation of context-layout-discovery.md
Commits workspace root initialization to disk
Generates a table of contents skeleton from a markdown index
Stages a resolved verb into one PENDING decision line
Writes stub file content with existence gate. Skips if target exists, creates parent directories and writes if missing.
No error handling guidance visible. Tools like 'apply_confirmed' and 'run_init' are destructive (WRITE risk) but no recovery guidance, retry classification, or confirmation patterns documented.
Naming inconsistency: 'build_boxes', 'compute_state', 'run_discover' lack clear verb_noun structure. 'render' is ambiguous (render what? to where?). 'apply_confirmed' is passive. Inconsistent naming increases LLM confusion when many tools are available.