Loading ToolBench
Knowledge Graph Engine MCP Server that provides access to the Knowledge Graph Engine through a simplified interface designed for AI assistants like Claude. Uses FastMCP with SSE transport for efficient communication.
The KG Engine MCP server provides 9 tools with generally good naming conventions (verb-noun pattern like process_text, search, get_node). Descriptions are present and moderately detailed (ranging 150-350 chars), explaining WHAT the tool does and WHEN to use it. However, there are critical gaps: several parameters lack descriptions or type specifications, output schemas are not explicitly documented, and error handling guidance is minimal. The tools follow a consistent domain model (knowledge graph operations) and compose reasonably well (e.g., process_text feeds into search/get_node), but the implementation lacks schema precision and recovery guidance expected of A-grade tooling.
Create a new relationship between two entities. Adds a triplet (subject-relationship-object) to the graph with metadata.
Permanently delete a relationship from the graph. PERMANENT operation - consider marking obsolete instead. WARNING: This action cannot be undone.
Delete a node from the graph. PERMANENT operation - consider marking relationships obsolete instead. Use cascade=True to delete all relationships. WARNING: Deletion is PERMANENT and cannot be undone. Cascade deletes ALL relationships (incoming and outgoing). Consider update_edge to mark relationships obsolete instead.
Retrieve all relationships connected to a specific entity. Explores the graph from a node and returns relationships within specified depth.
Retrieve comprehensive statistics about the knowledge graph. Returns node counts, relationship counts, graph metrics, and database health information.
Output schemas not documented for any tool. LLMs cannot plan downstream operations or extract required fields without knowing return structure.
Parameter schemas lack formal constraints. Properties objects (update_node, update_edge) use type 'object' with loose descriptions instead of formally constraining allowed keys and value types via JSON Schema.
Enum constraints not formalized in schema. search_type and status values are described as strings but not declared as JSON Schema enums, forcing LLMs to guess or hallucinate values.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Process natural language text to extract and store knowledge in the graph. Analyzes text using AI to extract entities (people, places, organizations) and their relationships. Handles duplicates, conflicts, and temporal tracking.
Search the knowledge graph using natural language. Combines graph traversal with semantic vector search for intelligent results with AI-generated answers.
Update properties of an existing relationship. Modify confidence scores, summaries, or mark relationships as obsolete/current.
Update properties of an existing node. Add or modify custom metadata like type, description, category, or domain-specific attributes.
Error handling and recovery guidance minimal. No descriptions of what errors can occur, what they mean, or how to recover. LLMs receive raw exceptions without context.
Destructive operations (delete_node, delete_edge) lack confirmation/dry-run pattern. Agents can permanently remove data without checkpoint or rollback option.
No pagination or result limiting guidance in search/get_node descriptions. Large graphs could return unbounded result sets, exhausting context windows. search has a limit parameter (good), but get_node does not.
No audit trail or permission checks visible in code. Tools accept any input without validation. No logging of who called what, when, or with what parameters.