Loading ToolBench
Full-stack TypeScript article management system for AI agents with MCP support, semantic search, embeddings, and background processing
This MCP server has 13 tools with generally good naming conventions and consistent schema structure. Tool names follow verb_noun patterns (list*, search*, read*, create*, update*, delete*, get*) which is commendable. However, there are significant gaps in parameter descriptions, output schema documentation, and error handling guidance. Many parameter descriptions are minimal (under 50 chars), and there is no documented guidance for error recovery or tool composition patterns. The server has solid foundational structure but lacks the depth expected for production-grade agent toolkits.
Create a new article with title and content
Delete an article permanently
Get embedding status for a specific article
Get progress of bulk embedding operations
Get current status and statistics of the embedding queue
List all articles with metadata (title, filename, creation date)
Get a unique list of all article folders to understand the knowledge repository structure
Parameter descriptions lack depth and actionable constraints. 'Optional folder path' appears in 5 tools but never specifies valid formats, whether '' vs '/' are equivalent, or whether relative paths are supported. This forces LLMs to guess at valid input formats.
Output schemas are not documented. The rubric requires documentation of what fields are returned (e.g., does listArticles return [{ title, filename, creationDate, ... }]? What does searchArticles return?). Without documented output schemas, LLMs cannot reliably chain tools or extract needed data for follow-up calls.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 70 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Search for multiple articles by title in a single request
Perform multiple semantic searches in a single request
Read the full content of a specific article
Search articles by title (partial match)
Perform semantic search on articles using embeddings
Update an existing article's title, content, and/or folder
deleteArticle has minimal description ('Delete an article permanently') without any error guidance, confirmation step, or recovery instructions. Destructive operations should include dry-run or explicit confirmation patterns to prevent agent mistakes.
No error handling documentation across any tool. Tools lack guidance on: (1) What errors can occur? (2) Are they retryable? (3) What should the LLM do next? For example, readArticle with an invalid filename should return 'File not found. Did you mean: [list of available files]?' instead of a bare 404.
Multi-variant tools (multiSearchArticles, multiSemanticSearch) lack documentation of batch semantics. If one query fails, are others skipped? Are partial results returned? This ambiguity causes agent confusion.
semanticSearch and multiSemanticSearch parameter 'k' has minimal description ('Number of results to return (default: 5, max: 100)') but omits important semantic details: what does 'max: 100' mean? Is this enforced? What happens if k=101 is passed? Should this be an enum or range constraint?
createArticle and updateArticle descriptions do not indicate whether they modify state synchronously or queue background work. The source mentions 'background embedding' but the tool descriptions are silent on this, leading to agent confusion about response latency and when results are available.
updateArticle marks 'title' and 'content' as required, but the description states 'and/or folder', implying partial updates. If only the folder should change, the LLM must still provide title and content, which is unintuitive and wastes tokens. Consider making all update fields optional.