Loading ToolBench
Memory database for LLM agents — persistent keyword + optional semantic memory, project namespacing, served over HTTP REST and MCP.
OpenChronicle MCP exhibits significant quality gaps across definition, schema, and documentation. While the server uses fastmcp (a production framework) and HTTP transport, the tool definitions lack the rigor required for agent reliability. Most tools have basic descriptions but lack comprehensive parameter documentation, input schema specifications, and structured output documentation. No tool annotations (readOnlyHint/destructiveHint) are visible despite clear risk classifications. Error handling is not documented. The codebase is not fully visible in the provided samples, preventing verification of actual schema implementations beyond file structure.
Retrieve context information
Standing rules and pinned memory management
Persist decisions, milestones, and context that should outlive the current session
Hybrid semantic + keyword retrieval scoped to a project
Seed memory from a repository's commit history
Create a new project namespace
List all projects
Show project details
Get system health and status
No input schemas visible in provided source code. Cannot verify parameter types, required fields, defaults, constraints, or formats. All 9 tools score 0 on schema evaluation.
Tool descriptions are brief (typically 50-65 chars) but lack WHEN to use guidance, prerequisites, or dependencies. E.g. 'memory_search' states 'Hybrid semantic + keyword retrieval scoped to a project' but does not explain: Must I set a project first? Does this require embeddings? What format are results?
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible. Risk classifications are provided in the server spec (WRITE vs READ_ONLY) but not surfaced in tool definitions where MCP clients can detect and warn about them.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
Output schema structure not documented. 'memory_search' promises 'Hybrid semantic + keyword retrieval' but no indication of what fields the response contains. LLMs cannot plan downstream tool calls or extract structured data without knowing response shape.
Parameter descriptions missing entirely. Source code does not expose parameter-level documentation. E.g. 'memory_search' likely accepts query strings and project IDs but no visibility into parameter names, types, defaults, or constraints.
Error handling guidance absent. Tools like 'onboard_git' (which clones repos) likely fail when git is not available or URLs are invalid, but no recovery hints are documented. Agents will not know whether to retry or ask the user.
Naming: 'context_get' is vague. Does it get agent context, project context, memory context, or user context? Rename to 'get_project_context' or 'get_memory_context' to disambiguate for LLMs.
Pagination not visible in tool documentation. If 'memory_search' or 'project_list' return many results, no limit/offset or cursor mechanism is documented. LLMs cannot iterate over large result sets without context window explosion.