Loading ToolBench
Lore is a semantic search MCP server for Claude Code session indexing. The server has 6 tools with generally good naming (verb-noun structure: search, get_context, index, list_sessions, manage_projects, status) and descriptions. However, there are significant gaps in parameter descriptions, schema completeness, and error handling guidance. Most tools lack explicit output schemas, making it difficult for LLMs to understand what fields will be returned. Several parameters are underdescribed or lack validation constraints. The codebase shows strong implementation (advisory locking, orphan pruning, embeddings) but the tool interface definitions lack the rigor needed for production agent composition.
Retrieve more conversation context around a specific search result. Use ONLY after calling search, when you need to see what was discussed before or after a result.
Index Claude Code sessions for search. No params = index all non-excluded projects. Pass 'project' with a path to index a specific project (even if excluded).
List all indexed Claude Code sessions. Use when the user wants to browse conversation history or find sessions by project/date.
Manage which projects are indexed. All projects are indexed by default (opt-out model). Use 'list' to see all projects and their status. Use 'exclude' to stop indexing a project and clean up its data. Use 'include' to undo an exclusion.
Search through past Claude Code conversations across all projects. Use when the user asks about previous discussions, past decisions, or anything from a prior conversation.
Check the health and progress of lore indexing. Shows indexing status, session counts, DB size. Use this to monitor indexing progress after calling index.
Missing output schemas for all tools. Descriptions state what tools do but do not document the structure or fields of returned results. This forces LLMs to infer response fields (e.g., what does search() return? chunk_id? score? content? metadata?), risking field mapping errors and broken tool chaining.
Parameter 'limit' appears in search() and list_sessions() but lacks numeric constraints (min/max). Unbounded numbers let LLMs pass absurd values (limit=999999) that could overload the server or exhaust context windows. Should specify range (e.g., 1-100, default 20).
manage_projects 'projects' parameter is an array but lacks constraints on array length or item format. The description says 'dir_name or path' but does not clarify how to distinguish them or what format is required. This invites malformed input.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
index tool accepts 'project' parameter as either 'path' or 'dir_name' but does not explain disambiguation or provide validation hints. If both formats are valid, parameter descriptions should show examples or state the priority order (e.g., 'Prefers dir_name if ambiguous').
No error recovery guidance in tool descriptions. E.g., search() may return no results, should the LLM try a broader query, check list_sessions to verify indexed sessions exist, or call status? Without recovery hints, agents stall on failures.
get_context 'direction' and 'count' parameters are optional with no defaults stated. LLMs cannot know: if I omit 'direction', do I get context before, after, or both? If I omit 'count', how many chunks? Unclear defaults lead to confused behavior.
index 'mode' parameter description says 'rebuild: deletes ALL indexed data' but does not warn that this is irreversible or require confirmation. Agents may accidentally invoke rebuild mode, wiping indexed history. Should support a dry-run or confirmation step.
search() description mentions 'session ID (UUID)' but does not explain how to obtain one. It says 'Use list_sessions to find session IDs' but the composition is unclear: must the LLM always call list_sessions first? Can search work without a session filter? Tool chaining should be more explicit.