Loading ToolBench
Interactive visual workspace for the Canonical Knowledge Structure ecosystem. A React-based frontend that connects to a cks-mcp backend server via MCP protocol to visualize, edit, and manage knowledge graphs.
CKS Studio exposes 18 tools with complete input schemas and descriptions, but quality is inconsistent. All tools have descriptions (10-200 chars, baseline 194), and parameters include types and descriptions. However, output schemas are undocumented, the code shows response normalization (normalizeCompactSubgraphResponse) but no formal schema declarations in tool definitions. Error handling is minimal; most tools lack recovery guidance. Naming is verb-first and clear (query_, serialize_, validate_, list_, search_, register_, etc.), following pattern:tool conventions. Parameter descriptions are adequate but lack constraints (enums, ranges, format specs). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications (READ_ONLY vs WRITE). Composition is reasonable, tools chain via session_id, but no pagination support visible, risking context window exhaustion on large graphs.
Resolves conflicts in inference results between Knowledge Structures
Checks the health and validity of a Knowledge Structure graph
Creates a copy of a registered graph with a new session ID
Compares two graphs and returns their differences
Applies evolution operations to a Knowledge Structure session (add/update/delete objects and relations)
Explains the differences between two Knowledge Structures
Explains inference results and reasoning for a Knowledge Structure
Output schemas undocumented. Code shows response normalization (normalizeCompactSubgraphResponse, getFullGraph) but tool definitions lack formal return type schemas. LLMs cannot plan downstream calls or extract fields without documented output structure.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are classified as READ_ONLY or WRITE in metadata, but MCP tool definitions lack these hints. Agents cannot distinguish safe retries from destructive operations without explicit annotations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Creates a link/relation between two graphs
Lists registered graphs from the Graph Gallery with optional filtering by tag, visibility, and team
Lists all versions of a registered graph
Merges two graphs into a single combined graph
Queries a subgraph from a Knowledge Structure session by seed node IDs and depth, returning nodes and edges in compact mode format
Registers a graph in the Graph Gallery with metadata including name, description, tags, and visibility settings
Searches registered graphs in the Graph Gallery by query string with optional filtering
Serializes a complete Knowledge Structure session to a canonical JSON representation
Removes a graph from the Graph Gallery registry by name, leaving the underlying session intact
Transitions a registered graph's lifecycle state through allowed state transitions
Validates a JSON knowledge structure and creates a new session, or validates imported graph data
Parameter constraints missing. 'depth' in query_subgraph lacks min/max bounds; 'visibility' in register_graph lacks enum constraint; 'new_state' in update_graph_lifecycle lacks allowed values. Descriptions mention constraints informally but JSON Schema lacks formal type/enum/pattern declarations.
No pagination support visible. list_graphs and search_graphs lack limit/offset or cursor parameters. Large graph galleries risk returning unbounded results, exhausting context windows and degrading LLM reasoning.
Error handling lacks recovery guidance. No visible error responses that tell LLMs what to do next (e.g., 'Graph not found. Try search_graphs() first.'). Agents receive failures but no actionable next steps.