Loading ToolBench
Git-backed wiki engine with MCP/ACP server — bring your own LLM
Strong foundation with 13 well-defined tools covering wiki lifecycle (create, register, list, remove, config, content read/write, search, ingest). All tools have descriptions (avg 120 chars) and explicit JSON schemas with typed parameters. Naming follows verb_noun pattern (wiki_spaces_*, wiki_content_*, wiki_search, wiki_list). However, output schemas are not documented, LLMs cannot predict response structure for chaining. Error handling lacks recovery guidance. Some parameter descriptions are terse (e.g., 'Target wiki name' repeated 8 times). No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels (WRITE, DESTRUCTIVE, READ_ONLY marked in metadata but not in schema).
Get, set, or list configuration values. action="get" returns the current value of a key; action="set" writes a new value; action="list" shows all key/value pairs for the target config. Use action="list" to discover all supported keys. Key namespaces: "global.*" (default_wiki); "defaults.*" (search_top_k, search_excerpt, search_sections, page_mode, list_page_size, output_format, facets_top_tags); "index.*" (auto_rebuild, auto_recovery, memory_budget_mb, tokenizer); "graph.*" (format, depth, output, snapshot, snapshot_keep, snapshot_format); "serve.*" (http, http_port, http_allowed_hosts, acp, acp_port). Omit --wiki to target the global config; pass --wiki <name> for per-wiki overrides.
Commit pending changes to git.
Create a page or section with scaffolded frontmatter.
Read full content of a page by slug or URI.
Write content to a page in the wiki tree. Content size is limited by defaults.max_content_bytes (default 10 MB); larger payloads are rejected with an error.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination) for wiki_search, wiki_list, wiki_content_read, wiki_spaces_list. This breaks tool chaining, agent cannot extract IDs or references for downstream calls.
No tool annotations in schemas. Risk levels (WRITE, DESTRUCTIVE, READ_ONLY) are metadata but not exposed via readOnlyHint/destructiveHint in JSON Schema. LLMs cannot infer safety constraints from schema alone.
Error handling lacks recovery guidance. No documented error cases, retryability, or actionable next steps. E.g., wiki_spaces_create with duplicate name, does it fail? Return a conflict? Suggest alternatives?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | <=2025-11-25 | v2 |
Validate, commit, and index files in the wiki tree.
Paginated page listing with filters.
Full-text BM25 search, returns ranked results.
Initialize a new wiki repository.
List all registered wiki spaces.
Register an existing wiki repository without creating files.
Unregister a wiki space from the config. Pass delete=true to also delete the wiki directory from disk (irreversible).
Set the default wiki space. Once set, tools that accept an optional wiki parameter will target this wiki when wiki is omitted.
Parameter descriptions are generic and repeated. 'Target wiki name' appears 8 times. Should clarify: 'Wiki name (omit to use default wiki)' vs 'Wiki name to set as default' vs 'Wiki name to remove'. Ambiguity forces LLM to guess intent.
No pagination guidance for wiki_list and wiki_search. Descriptions mention 'top_k' and 'page_size' but do not document total count, next_cursor, or max result limits. LLMs cannot plan multi-page retrieval.