Loading ToolBench
Model Context Protocol server for AKB (Agent Knowledge Base) — organizational memory system for AI agents with vault management, document storage, semantic search, and knowledge graph capabilities.
AKB MCP Server provides 4 tools with mixed quality. All tools have descriptions and input schemas are visible, but there are significant gaps in parameter descriptions, output schema documentation, and error handling guidance. Tool naming follows verb_noun convention (good), but descriptions vary widely in completeness. The server demonstrates awareness of structured output patterns (e.g., akb_list_vaults mentions response format) but fails to document full output schemas. Parameter descriptions are present but often lack constraint information (ranges, patterns, format hints). No evidence of tool annotations (readOnlyHint, destructiveHint, idempotentHint), error recovery guidance, or dependency documentation between tools.
Create a new knowledge base vault (a separate, access-controlled repository for documents). Its name is unique across the AKB installation and becomes part of the canonical akb:// URI. Pass `external_git` to instead create a read-only mirror of an upstream git repo — the vault tracks the remote on a polling schedule and rejects user writes.
Retrieve a document by its URI. Returns full content with metadata.
List accessible vaults as {name, description} pairs. Response is slim — no metadata (id/role/created_at) — to fit large tenants in agent context. Returns {vaults, total, returned, truncated?, hint?}. Optional args: - filter: substring match on name+description (case-insensitive). Use to narrow to a domain (e.g. filter='finance'). - limit / offset: pagination when there are many matches. - include_archived: include archived vaults (default false).
Store a new document. The response carries the canonical `uri` — `akb://{vault}/coll/{collection}/doc/{filename}` when stored under a collection, or `akb://{vault}/doc/{filename}` at the vault root. Use that URI to address the document from every other tool. Automatically chunked and indexed for semantic search.
akb_get has minimal description ('Retrieve a document by its URI. Returns full content with metadata.'). Missing: WHEN to call vs similar tools, what metadata is included, what format the response uses, dependency on akb_put/akb_list_vaults. Description is 82 chars but provides minimal actionable context for LLM tool selection.
No output schemas documented for any tool. akb_list_vaults mentions response format in text ('Returns {vaults, total, returned, truncated?, hint?}') but this is prose, not a structured schema. LLMs cannot plan downstream calls or validate responses without formal output schema definitions. All 4 tools affected.
Parameter descriptions lack constraint information. akb_create_vault.name: description says 'lowercase letters and digits, with single hyphens between words' but is prose, not a regex pattern or JSON Schema constraint. akb_put.limit, akb_list_vaults.limit: no min/max bounds stated. akb_create_vault.external_git.poll_interval_secs has minimum=60 in schema but this is not mentioned in description text.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
No error handling or recovery guidance in any tool description. No mention of what happens on name collision (akb_create_vault), what errors may occur on document store failure (akb_put), or how to handle missing documents (akb_get). LLM has no guidance on retryability, user-fixable vs fatal errors, or next steps on failure.
Tool naming does not distinguish between similar operations clearly enough for disambiguation. akb_put stores documents; akb_get retrieves them. But no companion tools for update_document or delete_document are mentioned. If they exist in the implementation but not exposed via MCP, that is incomplete. If they don't exist, the naming set is asymmetric (only put/get, no update/delete), odd for a knowledge base.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present in any tool. akb_list_vaults and akb_get are clearly read-only; akb_create_vault and akb_put are destructive/write operations. These hints would help LLMs reason about safe parallelization and retry behavior.
No dependency hints or chaining guidance. akb_put description mentions 'Use that URI to address the document from every other tool' but never explicitly states which tools use the URI it returns. No guidance like 'Call akb_list_vaults first to find available vaults before calling akb_put.' Multi-tool workflows are left implicit.
akb_put accepts both 'parent' and 'vault'+'collection' parameters; description says these are conditionally required but does not explicitly state mutual exclusivity rules or precedence. An LLM may pass all three, causing ambiguity or error.
akb_create_vault 'template' parameter has enum=[] (empty set), making it unconstrained. Either the enum should list valid templates, or the parameter should be removed if templates are not yet supported.
Response limit enforcement unclear. akb_list_vaults mentions 'truncated?' and 'hint?' fields but does not document what triggers truncation or what the default/max result count is. Without explicit limits, large tenants could return thousands of vaults, exhausting context.