Model Context Protocol server for Datomic database operations, providing tools to connect to databases, manage schemas, add/query data, and perform transactions
This Datomic MCP server has 3 tools with visible schemas and descriptions, but quality is inconsistent. Naming is reasonable (verb_noun pattern), but descriptions are sparse and lack context for LLM decision-making. Parameter descriptions are minimal. Output schemas are not documented. No error recovery guidance. The tools are straightforward database operations, but lack the precision and completeness expected for production use.
Add data to the Datomic database
Connect to a Datomic database
Install schema to the Datomic database
No output schemas documented for any tool. LLMs cannot predict return structure, making downstream chaining difficult and increasing error likelihood.
Parameter descriptions are minimal or absent. Each parameter object in schema lacks a 'description' field. LLMs cannot infer what values are valid or what each parameter does.
install_schema and add_data have all optional parameters with no clear guidance on which combination is valid. Should schema and schema-file be mutually exclusive? Is use-default a fallback? LLMs will guess and likely pass conflicting parameters.
No error recovery guidance. Code shows catch blocks returning bare error messages like 'Error connecting to database: [message]'. LLMs receive no actionable next steps, should they retry? Call a different tool? Ask the user?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
Tool descriptions lack context about prerequisites and dependencies. 'install_schema' and 'add_data' require prior 'connect_db', but this dependency is not stated in the descriptions. An LLM might attempt operations in wrong order.
Global state (conn-atom, db-uri-atom) is used to track connections. Protocol-level statefulness violates the stateless request model of MCP 2026-07-28. Each request should be self-contained.
No validation on file paths before reading. Code calls 'read-file-content' and 'load-schema-from-file' without checking for path traversal or unauthorized file access. Untrusted input (file paths) could be exploited.
EDN string parameters accept arbitrary Clojure code. 'read-string' on untrusted input is a code injection vulnerability. LLM-supplied EDN strings can execute arbitrary code.