Loading ToolBench
A versioned, append-only document store with hybrid search (lexical + vector), context packing, and MCP integration. Provides REST API and MCP server for retrieving cited, checksummed context from stored documents.
BaseMouse Core presents 11 well-structured tools with consistent naming patterns (verb_noun: search, get_context_pack, create_document, etc.) and comprehensive parameter descriptions. All tools have documented input schemas with type definitions and field descriptions. However, output schemas are not explicitly documented in the source code, the server defines inputs but does not include return type specifications, parameter constraints, or guidance on error recovery. Most tools follow the chat-data-model (natural identifiers like document IDs, query strings) rather than opaque system IDs. The codebase shows careful design (optimistic locking, idempotent upsert, soft-delete preservation) but lacks explicit error classification and recovery guidance in tool descriptions. Pagination is well-implemented for list operations (limit, offset), but some tool descriptions could better explain prerequisite calls or next-step guidance.
Claim a free or trial API key using a one-time authorization code. Returns the key (shown once) and workspace ID.
Create a new document with id, title, body, type, and optional tags. Returns the created document with version and timestamp.
Soft-delete a document by ID. Marks as deleted; append-only history is preserved.
Retrieve the complete append-only revision history of a document. Returns all historical versions with snapshots and timestamps.
Retrieve a cited, checksummed context pack of documents matching a query. Returns entries with provenance (checksum, version) and citations.
List all documents in the repository with pagination. Returns document metadata (id, title, type, tags, version, timestamps).
Output schemas not documented. Tools like create_document, update_document, and upsert_document lack explicit return type specifications. LLMs cannot plan downstream calls or extract required fields (e.g., returned version, timestamp, or checksum) without visible output schema.
Error recovery guidance missing from descriptions. Tools like delete_document (soft-delete, preserves history) and rotate_key (invalidates previous key) perform irreversible or state-changing operations but lack guidance on what errors might occur or how to recover. Descriptions should state: 'If rotation fails, the previous key remains valid until the new one is confirmed.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 75 | 2026-07-28+ | v2 |
Rotate the authenticated API key to a new one. Returns the new key (shown once). Previous key is invalidated.
Search documents by query, type, and tag. Supports lexical and hybrid (graph-aware) retrieval modes.
Update an existing document's fields (title, body, type, tags) with optimistic locking by version. Returns the updated document with incremented version.
Idempotent upsert: create if not exists, or update if exists. Server owns the create/update/unchanged decision and normalizes trimmed fields. Tags merge additively server-side. Never grows append-only history on unchanged content.
Retrieve API usage statistics for the authenticated key. Returns request counts and quota information.
Parameter constraints not fully expressed. The create_document 'body' parameter states 'non-empty, max 256KB' only in the description text; JSON Schema max/minLength properties are absent. Similarly, 'id' should express the pattern (lowercase a-z0-9-) as a JSON Schema 'pattern' property, not just in description text. LLMs cannot read description text for constraints, they need formal schema properties.
Pagination guidance incomplete. list_repository accepts limit and offset but does not document a total_count return field or next_cursor. Without explicit total count or continuation token, LLMs cannot efficiently iterate through large document sets or know when iteration is complete.
Tool-chaining field presence unclear. After search or get_context_pack, would an agent need to call get_context_pack again, or does search already return checksums and versions? After create_document, what fields does the response include (id, version, timestamp, checksum)? Without explicit field documentation, agents risk misunderstanding what they can use in the next step.
Semantic ambiguity in parameter names. 'tags' parameter in create_document/update_document/upsert_document should clarify: are tags additive (merge) or replacement? upsert_document description says 'Tags merge additively server-side' but this is not stated in create_document or update_document descriptions, creating inconsistency.
State-changing operations lack confirmation or dry-run modes. delete_document and rotate_key are destructive or irreversible but offer no confirmation step, dry-run option, or 'are you sure?' pattern. An agent bug could accidentally delete all documents or rotate keys unexpectedly.