Loading ToolBench
Unified knowledge management MCP server with document intelligence and research workflows
The Lore Knowledge MCP server has 24 tools with generally complete parameter schemas and descriptions, but quality is inconsistent. Most tools follow verb_noun naming (kb_list, kb_create, kb_delete) and include input parameter schemas with types and descriptions. However, output schemas are not documented, critical for LLM planning and chaining. Several tools lack clarity around what they return (e.g., kb_embedding_status returns no documented structure). Parameter descriptions are present but often minimal (10-30 chars), below the 50-200 char baseline for LLM optimization. Error handling is mentioned (confirm_production flags on destructive ops) but recovery guidance is absent, LLMs won't know what to do if kb_delete fails. Tool composition is reasonable (each does one thing), but several tools seem to overlap in intent (kb_search vs search_knowledge_base, investigation_* vs kb_*, multi_search vs search_corpora/transcripts/local_files). The server lacks tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite the MCP 2026-07-28 spec requiring them for agent safety. No pagination in list tools is documented, risking context window exhaustion.
Create a new investigation entry for debugging notes and experiments
Delete an investigation entry
List investigations (debugging notes and structured experiments)
List all experiments within investigations
Update an existing investigation entry
Create a new journal entry for decision logging and config snapshots
Delete a journal entry
List journal entries (decision log and config snapshots)
Output schemas are not documented for any tool. LLMs cannot plan multi-step workflows or chain tools if they don't know what fields to expect. This is a critical gap blocking composition and increases error rates.
Multiple tools perform overlapping searches: kb_search, search_knowledge_base, multi_search, search_corpora, search_transcripts, search_local_files. The LLM must reason about which to call, wasting tokens and inviting wrong choices. Consolidate into a single unified search with optional source/type filters.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Update an existing journal entry
Create a new knowledge base entry with optional attribution and verification tracking
Delete a knowledge base entry (requires production confirmation in production environment)
Get the status of semantic embedding indexing for the knowledge base
Retrieve multiple knowledge base entries by their IDs
Bulk ingest markdown/text files from a directory into the knowledge base
List knowledge base entries with optional filtering by topic
Search knowledge base entries using full-text search
Update an existing knowledge base entry
List indexed MCP tools with search and filtering
Scan MCP servers and index their tools for discovery
Multi-source search across knowledge base, investigations, journal, and local files
Search corpora in configured INGEST_ROOT directory
Search the knowledge base with full-text, semantic, or lexical search
Search local files in configured knowledge data directory
Search transcripts in configured LATVIAN_LEARNING_ROOT directory
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are missing. Per MCP 2026-07-28 spec, destructive tools like kb_delete, investigation_delete, journal_delete MUST include destructiveHint=true. This is required for agent safety and proper planning.
Parameter descriptions are too brief (10-40 chars). Baseline for LLM-optimized descriptions is 50-200 chars. For example, kb_embedding_status has no input description for empty schema. kb_ingest_dir's dry_run description lacks explanation of what happens when dry_run=true vs false.
Pagination is not explicitly documented. kb_list has 'limit' and 'offset' parameters, but there is no documented total count or next_cursor returned. When LLMs retrieve large result sets, they should know whether more results are available to prevent context window exhaustion.
Error recovery guidance is absent. When kb_delete fails or kb_create conflicts, the error response should guide the LLM (e.g., 'Entry exists: try kb_update instead' or 'Delete failed: verify confirmation flag'). Currently, errors are likely raw API responses that LLMs cannot act on.
confirm_production flags (on kb_delete, kb_ingest_dir, investigation_delete, journal_delete) are good safeguards, but there is no documentation of what happens if the flag is missing or false. Does the tool refuse to run, or does it silently no-op? This ambiguity can lead to failed operations with no clear feedback.
Tool naming overlaps: investigation_* tools duplicate kb_* tools (both create entries, both list, both delete). The distinction between 'investigation' and 'knowledge base' is not explained. If they truly serve different purposes, the descriptions should clarify when to use which. If they are redundant, consolidate.