Loading ToolBench
Knowledge wiki with semantic search, research, and knowledge graph. MCP server exposing wiki operations as tools with full-text search, backlink indexing, query language, and Wikipedia integration.
The server provides 10 tools with basic descriptions and input schemas visible in the code. However, the definitions have significant gaps: descriptions are functional but often lack depth and context; several parameters have minimal or no descriptions; output schemas are not documented in the visible code; and error handling guidance is absent. The tool naming convention is reasonable (wiki_* prefix) but descriptions do not consistently explain WHEN to use each tool vs. alternatives, nor do they guide LLM recovery from errors. The schema definitions are present for inputs but lack type strictness (many use generic 'string' without enum constraints where applicable). Per-tool analysis reveals uneven quality across the 10 tools.
Get all pages that link to a given page, plus unlinked mentions.
Create or get today's daily note.
Analyze content gaps: missing pages, structural holes, stale content.
List wiki pages, optionally filtered by type.
Execute a frontmatter query (Dataview-like syntax). Example queries: - SELECT title, type FROM pages WHERE confidence = "high" SORT BY updated DESC - COUNT type FROM pages - LIST FROM pages WHERE tags CONTAINS "research"
Read a wiki page by slug. Returns the full markdown content.
Search the wiki using TF-IDF full-text search.
Missing output schemas. No documented return types visible in source for any tool. LLMs cannot plan chained calls or extract required fields without knowing what each tool returns.
wiki_write and wiki_daily lack error handling guidance. They modify state (WRITE operations) but provide no recovery instructions if creation fails, no confirmation step for destructive updates, and no idempotency hints. Agents cannot determine if a failed write should be retried.
Parameter descriptions are sparse or generic. 'type_filter' in wiki_list has a description with examples ('concept', 'source', 'entity') but no enum constraint, LLMs may hallucinate invalid values. 'slug' parameters lack format guidance (e.g., lowercase, hyphen-separated). 'query' in wiki_query lacks syntax documentation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Get wiki statistics: page count, types, confidence distribution.
Search Wikipedia articles via the MediaWiki Action API.
Create or update a wiki page.
Tool descriptions do not disambiguate between similar tools. wiki_search and wiki_wikipedia_search both search; wiki_list lists pages. LLM cannot infer when to prefer one over another without meta guidance ('Use wiki_search for internal wiki content; use wiki_wikipedia_search for external encyclopedia results').
wiki_write description ('Create or update a wiki page') does not clarify the state-changing nature or warn of potential data loss if 'content' overwrites existing data. No idempotency hint provided.
wiki_query description references 'Dataview-like syntax' and provides examples, but does not formally specify the query language grammar, supported keywords, or error modes. LLMs may construct syntactically invalid queries.
No pagination or limit enforcement visible in schemas for wiki_list or wiki_search. Descriptions mention defaults (10, 50) but no explicit maximum stated. Large result sets could exhaust context windows.
wiki_stats and wiki_gaps have minimal descriptions ('Get wiki statistics...', 'Analyze content gaps...') and empty input schemas. LLMs lack context about what these tools return or how they differ from discovery tools like wiki_list.