Loading ToolBench
Persistent memory layer for AI coding agents — MCP server with current-state retrieval and supersession tracking
Lint-AI is a memory indexing MCP server with 11 tools. While it demonstrates some structure, there are significant gaps in parameter descriptions, input schema completeness, and output documentation. Most tools have generic or missing descriptions. Parameter schemas are partially visible but lack descriptions for most fields. The server appears to be in early development (0.2.1) and lacks the rigor expected of production-grade agent tools.
Add or upsert a memory into the index.
Batch add or upsert memories into the index.
Delete a memory from the index.
Delete a specific memory by ID.
Mark memories as expired based on timestamp criteria.
Retrieve a specific memory by ID.
List indexed memories with bounded content previews.
9 of 11 tools have NO visible input schemas in source code. Cannot verify parameter structure, types, or constraints for add, add_batch, delete, supersede, expire, get_memory, update_memory, delete_memory, refresh_memories. Source references point to src/bin/server.rs but schema definitions are not provided in submitted code.
9 of 11 tools have generic, uninformative, or missing descriptions (under 20 characters or just the bare verb). Examples: 'Add or upsert a memory' (no WHEN to call, no side effects clarity), 'Delete a memory' (no error handling guidance), 'Update a specific memory by ID' (no parameter details). LLMs cannot distinguish between similar tools or reason about when to invoke them.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | <=2025-11-25 | v2 |
Refresh and rebuild the memory index.
Search indexed memories with provider filtering and result ranking.
Mark a memory as superseded by another memory.
Update a specific memory by ID.
Destructive operations (delete, delete_memory) lack confirmation or dry-run support. Agents can irreversibly delete memories with no ability to preview or confirm first. No recovery guidance in error responses.
Parameter descriptions missing or extremely sparse. The 'provider' parameter in search is well-described with enum values, but other tools (add, update_memory, etc.) show no visible parameter documentation in source. Cannot verify that parameters like 'memory_content', 'memory_id', 'timestamp_criteria' have descriptions for LLM guidance.
No output schema documentation visible for any tool. search_results() and list_memories() format output in code, but LLMs have no declared schema for what fields to expect (e.g., does delete return {success: bool, id: string} or just null?). Agents cannot plan downstream tool calls without knowing response structure.
Error handling does not provide recovery guidance. No evidence in source that tools return actionable error messages like 'Memory not found. Try search() first.' or categorize errors as retryable vs. user-fixable. Agents receive no direction on next steps when calls fail.
Tool naming could be clearer for related operations. 'delete' and 'delete_memory' both delete memories, distinction unclear (one by content hash? One by ID?). Similarly, 'supersede' vs 'expire', LLMs may conflate these. Names should clarify intent: delete_memory_by_id vs delete_by_provider vs expire_by_timestamp.
Batch operation (add_batch) lacks per-item success/failure reporting. If 1 of 100 memories fails to add, does the tool return a blanket error or partial results with details on which items failed? Unclear error semantics force agents to retry the entire batch.