Loading ToolBench
Universal AI memory layer - cross-client, cross-repo context management with RAG. Persistent memory for AI coding agents with search, save, and recall capabilities.
ContextFS has 14 tools with mixed quality. Naming is generally clear and verb-forward (contextfs_sync_*, contextfs_save, contextfs_search, contextfs_list_*), following the verb_noun convention. Descriptions are present for all tools and vary from adequate to good (ranging 50-250 chars). Schemas are well-defined with proper JSON Schema structure, types, and parameter descriptions. However, there are gaps in output schema documentation, error handling guidance, and some descriptions lack specificity about when/why to use certain tools. The sync tools (contextfs_sync_register through contextfs_sync_status) are well-designed with clear purposes. The memory tools (contextfs_save through contextfs_list) cover a coherent feature set but lack guidance on error recovery and what to do when search returns no results. Overall functional and usable, but falls short of A-grade quality due to incomplete output documentation and missing error recovery patterns.
Get the JSON schema for a memory type. Use to understand what structured_data fields are available for each type.
List recent memories
List all projects with saved memories (projects group memories across repos)
List all repositories with saved memories
List all source tools (Claude, Gemini, etc.) with saved memories
Recall a specific memory by ID
Save a memory to ContextFS. Use for facts, decisions, procedures, or session summaries.
Missing output schema documentation. Tools return responses (e.g., contextfs_sync_register returns device_id, device_name, platform, registered_at) but there is no formal output schema specification visible in the tool definitions. LLMs cannot plan downstream calls without knowing what fields to expect.
Error handling lacks recovery guidance. Tools do not document what happens on failure (e.g., when sync fails, when search returns no results, when a memory ID is not found) or what the LLM should do next (retry, call a different tool, ask the user). The code shows basic try-catch that returns {success: False, error: str(e)}, but no structured error classification (retryable, user-fixable, fatal).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 59 | - | v1 |
Search memories using hybrid search (combines keyword + semantic). Supports cross-repo search.
Full bidirectional sync with server
Content-addressed sync (Merkle-style, idempotent). Compares local content hashes with server state. Run it 100 times, always correct result.
Pull changes from sync server
Push local changes to sync server
Register this device with a sync server for multi-device memory synchronization
Get sync status from server
Discovery/list tools have minimal descriptions. contextfs_list_repos, contextfs_list_tools, and contextfs_list_projects all have descriptions under 70 characters ('List all repositories with saved memories'). These do not explain when to call them or what structure they reveal. Description should include: 'Call to discover available repositories before filtering searches' or similar dependency hint.
Parameter relationships undocumented. contextfs_save has both 'save_session' (enum: current|previous) and 'label' parameters, but the description does not explain whether 'label' only applies if save_session is set, or if it works independently. Undocumented dependencies cause silent misuse.
No confirmation pattern for destructive sync operations. contextfs_sync_push and contextfs_sync_all perform WRITE operations (specified in Risk: WRITE) but lack a dry-run option or confirmation step. An LLM could accidentally push incorrect or stale data without review.
Pagination missing from list/search tools. contextfs_search and contextfs_list both accept a 'limit' parameter but do not document offset/cursor or return a 'total_count' or 'next_cursor'. If search returns 1000 results, the LLM cannot navigate beyond the limit. Baseline tooling pattern requires pagination support.
No field naming consistency guarantee between tools. contextfs_search returns results but does not document whether they include 'id', 'memory_id', or another field name. If contextfs_recall expects 'id', there is a risk the LLM extracts 'memory_id' from search results and fails the lookup.