Loading ToolBench
Self-hosted knowledge engine: ingest anything, build a knowledge graph, query it over MCP. Provides MCP tools for knowledge graph query, entity extraction, signal management, and graph maintenance.
IMI provides 20 tools with mostly complete schemas and descriptions, but exhibits inconsistencies in naming clarity, parameter documentation, and error handling guidance. Tool names follow verb_noun convention (search_knowledge_graph, list_entities, graph_add_node), which is good. However, descriptions vary widely in quality, some are excellent (find_related_entities with 280+ chars explaining two modes), while others are minimal (read_document: 34 chars, below the 50-char baseline for clarity). Parameter descriptions are present but often lack constraint details (e.g., max_results lacks min/max bounds). Output schemas are not documented in the provided source. Duplicate tool names (extract_entities appears twice, tools 4 and 17) suggest registration inconsistency. Error handling is absent, no guidance on retryability, user-fixable vs. fatal errors, or recovery paths. Destructive tools (delete_signal, graph_delete_node, graph_merge_nodes) lack confirmation or dry-run patterns.
Permanently remove a signal
Extract decisions from text
Extract entities from text
Extract entities from text using Semantica (preferred) or entity brain.
Extract patterns from text
Extract risks from text
Traverse the graph from one entity to its directly connected entities. Two modes (set via the 'mode' parameter): - mode='neighbors' (default): returns the list of neighboring entities, each with the relationship type connecting them. Optionally filter by relationship_type. - mode='types_only': returns just an inventory of which relationship types this entity has (outgoing + incoming) and how many of each, without the full neighbor list. Useful as a quick discovery step before deciding which relationship_type to traverse. 'Outgoing' = edges where this entity is the source; 'incoming' = edges where this entity is the target.
Destructive tools (delete_signal, graph_delete_node, graph_delete_edge, graph_merge_nodes) lack confirmation or dry-run patterns. No guidance on irreversibility or recovery. Agents can permanently destroy data without safeguards.
Duplicate tool registration: extract_entities appears twice (tools 4 and 17) with identical schemas but different file locations. This creates ambiguity for LLM tool selection and suggests incomplete deduplication.
Minimal descriptions on 8 tools (read_document, extract_entities, update_signal, delete_signal, graph_delete_node, graph_merge_nodes, extract_decisions, extract_patterns, extract_risks). Descriptions under 40 chars lack context for LLM selection. Baseline is 50-200 chars.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Look up a single entity by its display name (case-insensitive, with partial-match fallback). Use this when you have a precise name and want the canonical entity ID and metadata. For fuzzy or keyword queries use search_knowledge_graph instead.
Add a relationship
Add a new entity node to the knowledge graph
Delete a relationship
Delete an entity node
Merge duplicate entities
Update relationship properties
Update node properties
List all entities of a given type, optionally with their relationships inline. Use this for bulk retrieval scoped to one type (e.g. 'all members'). When include_relationships=true, you usually do NOT need a follow-up find_related_entities call — the data is already on each entity. Use attribute_filter to pre-filter by attribute values (e.g. attribute_filter='west coast' returns only entities whose attributes contain that substring).
Read document content from the repository
Fuzzy/keyword search across entity names and string attributes. Returns ranked matches (highest score first). Use this when you don't know the exact entity name. For exact-name lookup use get_entity_by_name; for type-scoped retrieval (all entities of a given type) use list_entities.
Search persisted meeting signals (decisions, action items, key points, insights). Source of truth is the SignalStore JSON files; results are filtered in-memory. When entity_id is provided, prefers a Neo4j graph-relationship lookup (signals explicitly linked to the entity in the graph) and falls back to JSON content-mention filtering if the graph is unavailable. Without entity_id, filters JSON directly.
Update signal status/content/owner/due_date
No output schemas documented. Tools return data but LLMs cannot plan downstream calls without knowing response structure. E.g., search_knowledge_graph returns 'ranked matches' but field names/types are not specified.
No error handling guidance. Tools lack recovery hints (e.g., 'entity not found, try search_knowledge_graph'). No categorization of retryable vs. fatal errors. Agents cannot self-correct on failures.