Loading ToolBench
Super Knowledge Base (SKB) — a local vector knowledge base. Each project may have a .skb/ folder with context documents. Use provision_skb to bootstrap a project, sync_skb to index it, then search_docs/search_code to query.
SKB server has 12 tools with mostly complete schemas and descriptions. Naming follows verb_noun convention (provision, sync, search, list, remove, reindex, export, import). Descriptions are present and contextual (avg ~120 chars), explaining WHAT and WHEN. However, several critical gaps: (1) No output schemas documented for any tool, LLMs cannot predict response structure for planning; (2) Parameter descriptions lack format/constraint details (e.g., 'project' param has no guidance on valid format, length, or resolution rules); (3) No error handling guidance, tools return dicts but no recovery hints; (4) Missing idempotency/retry semantics for destructive ops (remove_project, reindex_project); (5) Tool descriptions do not state whether operations are safe to retry or have side effects. Strengths: all tools have descriptions >20 chars, all params have type annotations, naming is clear and action-oriented.
Export vector index as gzipped JSONL (.jsonl.gz). Exports all ChromaDB chunks and embeddings for a project as a compressed JSONL file. Fast to import (no re-embedding needed), but requires the same embedding model.
Export .skb/ source files as a portable .tar.gz archive. Creates a tar.gz containing all files from the project's .skb/ folder plus a manifest.json. The recipient can import this archive to recreate the .skb/ folder and rebuild the index.
Import a gzipped JSONL index archive into ChromaDB. Imports pre-computed embeddings from a .jsonl.gz archive (created by export_index) directly into ChromaDB, bypassing the embedding step.
Import a source archive into a project's .skb/ folder. Extracts a .tar.gz source archive (created by export_skb) into the target project's .skb/ folder and optionally rebuilds the index.
List all indexed files for a project with metadata. Shows source paths, chunk counts, and last synced timestamps for all documents in a project's knowledge base.
No output schemas documented. Tools return dicts (e.g., search_docs returns {query, results, count, scope}) but LLMs cannot predict structure for downstream planning or field extraction.
Parameter descriptions lack format/constraint details. 'project' param appears in 6 tools but has no guidance on valid format, length, or how it resolves (project name vs directory name). 'n_results' has no min/max bounds.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
List all indexed projects with document and chunk counts. Shows every project that has been synced into the knowledge base.
Provision SKB into the current project. Creates a local `.skb/` folder, installs the project-local `skb` skill, writes `.claude/CLAUDE-skb.md`, and wires `CLAUDE.md` to import it.
Force a full reindex: delete all indexed data for a project and rebuild from scratch. Use when the index is corrupted, embeddings need regenerating, or you want a clean slate without manually removing and re-syncing.
Remove all indexed data for a project. Use when a project is archived or you want to clear its knowledge base.
Search the knowledge base for code examples and reference implementations. Filters results to code file types only. Use when looking for code patterns, snippets, or implementation examples from .skb/.
Search the project knowledge base for relevant documentation, design decisions, API references, and code examples. Use this when the user asks about project architecture, conventions, or implementation details instead of asking them to provide files. Searches the .skb/ indexed documents semantically.
Scan the .skb/ folder in the project directory and ingest/update all files. Call this at the start of a session or after adding new files to .skb/.
Destructive operations (remove_project, reindex_project) lack confirmation/dry-run support and error recovery guidance. No indication whether operations are idempotent or have side effects.
No error handling guidance. Tools return success/failure dicts but do not tell LLMs what to do on failure (retry? ask user? fatal?). E.g., sync_skb could fail if .skb/ is missing, but no recovery hint provided.
Tool descriptions do not state whether operations modify state or are read-only. Agents need to know which calls are safe to retry. E.g., sync_skb description does not say 'This modifies the index' or 'This is idempotent'.