Loading ToolBench
MCP knowledge base server for AI agents via HTTP. Provides tools for searching, reading, creating, updating, and deleting knowledge entries organized by kind, language, domain, project, and tags.
MCPedia demonstrates solid definition quality with consistent naming conventions, clear action verbs, and comprehensive parameter documentation across 8 tools. All tools follow verb_noun naming (search_, get_, list_, create_, update_, delete_). Parameter schemas are well-typed with descriptions. However, tool descriptions are functional but somewhat generic, lacking the depth of guidance needed for optimal LLM tool selection (e.g., when to choose search_entries vs get_entries_by_context). Output schemas are not explicitly documented in the source code. Error handling descriptions are minimal. Tool annotations (readOnlyHint, destructiveHint) are not present despite clear risk classification.
Create a new knowledge entry with slug, title, content, and optional metadata. Checks database lock status. Returns created entry with ID and timestamps.
Delete an entry by slug. Removes the entry and all associated data (tags, stats). Checks database lock status.
Get entries matching multiple filters (kind, language, domain, project, tags) without full-text search.
Get a full entry by slug, including all content, metadata, and tags. Increments read counter.
List all entries without content, optionally filtered by kind, language, domain, or project.
List all tags in the knowledge base with their usage counts.
Tool descriptions lack disambiguation guidance. When search_entries, get_entries_by_context, and list_entries all retrieve entries, the descriptions do not explain when to use each tool instead of the others. This forces LLMs to guess or try multiple tools.
Output schemas are not documented in source code. The code defines input parameters clearly but does not specify what fields are returned for each tool (e.g., does get_entry return just the content, or also metadata like version, tags, read_counter?). This forces LLMs to infer response structure.
Tool annotations for destructive and read-only operations are missing. Despite clear risk classification (READ_ONLY, WRITE, DESTRUCTIVE), the MCP schema does not include readOnlyHint, destructiveHint, or idempotentHint annotations. This prevents clients from applying appropriate safeguards.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | C | 65 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Search entries using full-text search across title, description, and content. Returns results with optional snippet and filters.
Update an existing entry by slug. Supports updating any combination of title, content, description, kind, language, domain, project, and tags. Increments version and updates timestamp. Checks database lock status.
No pagination guidance in list_entries and get_entries_by_context. Both tools accept a limit parameter but do not indicate whether they return a total count, next_cursor, or have_more flag. Large result sets could exceed context windows without clear pagination strategy.
Error handling descriptions are minimal. Tool descriptions do not indicate what errors can occur (e.g., 'slug not found', 'database locked', 'content exceeds 32KB') or how to recover. Error messages from the server are not documented.
Parameter 'kind' accepts enumerated values (skill, rule, context, pattern, reference, guide) but this enum constraint is not formalized in the JSON schema. Descriptions say 'Filter by entry kind (skill, rule, context, pattern, reference, guide)' but do not declare an enum type.
Database lock mechanism is documented in create_entry, update_entry, and delete_entry descriptions but no tool is provided to check lock status or understand when operations will be rejected. Agents cannot plan around this proactively.