Loading ToolBench
An MCP server providing tools for working with Datascript databases, including database initialization, data operations, querying, visualization, and file system access
This server has 22 tools across database operations, file I/O, visualization, and shell execution. While schemas are present for all tools and descriptions exist, quality is inconsistent. Most critical issues: (1) Tools like 'clojure_eval' and 'execute_command' are extremely dangerous with no security warnings or error handling guidance in descriptions. (2) Parameter descriptions are often minimal, many lack format specifications, constraints, or usage guidance. (3) Output schemas are completely undocumented; LLMs don't know what fields to expect from results. (4) Error handling is absent, no recovery guidance, no retryability hints. (5) Some parameter relationships (e.g., 'schema' vs 'schema-file' as mutually exclusive options) are not clearly documented. The server follows basic JSON Schema structure but falls well short of production-grade tool definition quality expected in the 54 Agentic Tool Patterns.
Add data to the Datascript database from string or file
Add data to the visualization database
Generates a bar chart SVG from labeled data
Takes a Clojure Expression and evaluates it in the user namespace. For example: provide "(+ 1 2)" and this will evaluate that and return 3
Executes a shell command and returns the output
Checks if a file or directory exists and returns detailed information about it
Generate a Graphviz DOT format graph from visualization database entities and relationships
Dangerous tools (clojure_eval, execute_command) lack security warnings, sandboxing guidance, or permission requirements in descriptions. Per pattern:secret-injection and pattern:permission-gate, these IRREVERSIBLE operations should require explicit authorization, list resource limits, and provide audit trail guidance.
Output schemas completely undocumented. LLMs don't know what fields to expect from any tool result. Per pattern:tool, every tool must document its return type/structure so agents can plan downstream calls and extract relevant fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
Get statistics about the current database
Get an entity by ID from the database
Initialize a new Datascript database with optional custom schema
Initialize visualization database with optional custom schema
Generates a line chart SVG from coordinate pairs
Lists the contents of a directory
Load a database from a file (Transit format)
Generates a network/relationship graph SVG. Takes nodes (array of strings) and edges (array of {from, to} objects)
Pull entities from the database using a pull pattern
Execute a Datascript query against the database
Reads the contents of a file and returns it as text
Retract (remove) facts from the database
Save the current database to a file in Transit format
Generates a scatter plot SVG from coordinate pairs
Writes content to a file. Can either overwrite or append to existing files
Parameter descriptions are minimal or absent detail on format, constraints, and valid values. Per pattern:constrained-input, tools like query, pull, retract should document EDN syntax expectations. Tools with enum-like values (e.g. output-format in generate_graph) lack enum declarations.
Destructive and state-modifying tools lack error guidance and recovery hints. Per pattern:recovery-guide, tools like retract, delete operations should explain what to do if something goes wrong, whether the operation is retryable, and if there's a compensation tool.
Parameter mutual exclusivity not documented. Tools like init_db have 'schema' and 'schema-file' as optional alternatives, but descriptions don't clarify which takes precedence or if both can be provided. Per pattern:tool-description, document parameter relationships explicitly.
Domain-specific jargon without clear explanations. 'Retract' is Datascript terminology but not obvious to LLMs unfamiliar with that system. Descriptions should clarify what 'retract' means (remove facts), what a 'datom' is, and provide examples or format guidance.
No idempotency guarantees documented. Per pattern:idempotent-operation, agents retry on ambiguous failures, tools should state whether repeated calls with same inputs produce same result or cause duplicate side effects (e.g., does add_data create duplicates if called twice with same entity?).
Lack of pagination and result limits. Tools like query, get_db_stats, list_directory could return very large results. Per pattern:paginated-result, tools returning lists should document result limits, accept limit/offset parameters, and indicate if results are truncated.