- Reliability 7/20
- The README and manifest give a clear startup path, a tool table, CLI arguments, Docker usage, and a release process, so the happy path is plausible. However, no source code, tests, or CI workflows are provided, so the MCP init/tool-list handshake and the match between declared and actual tools cannot be verified. Error handling and edge cases are thinly evidenced, so under the static calibration rule the score cannot exceed 12; I assign 7.
- Security and permissions 13/20
- The server defaults to read-only, requires the explicit --read-write flag for writes, requires --allow-switch-databases for runtime database switching, and offers --motherduck-saas-mode to restrict local file access. Tokens and AWS credentials are marked secret in the manifest. The README explicitly warns that read-only mode still permits local filesystem access and DuckDB setting changes, and recommends MotherDuck Remote MCP for third-party access; data-flow disclosure is fairly clear. However, without source code we cannot verify enforcement of these permissions or any confirmation mechanism for dangerous operations, and no security reporting channel is shown. No real tokens, malware, or other red-line issues are present, so I assign 13.
- Maintenance 12/20
- The repository has an MIT license, version 1.0.7, a documented release process via GitHub Action to PyPI/MCP registry, and is not archived. But there is no evidence of commit frequency, issue response time, dependency update practices, or a security-response channel, leaving governance gaps. Stars are only a discovery signal and add no points, so I assign 12.
- Documentation 15/20
- The README is layered and practical: quick start, multi-client configuration examples, CLI parameters, environment variables, Docker, troubleshooting, security guidance, and explicit disclosures of row/character limits and migration changes. It lacks cost information, the troubleshooting section is thin, and without source/tests we cannot confirm full alignment between docs and behavior, so I assign 15.
- Setup experience 13/20
- Setup is clear and low-friction: uv/uvx plus a JSON snippet, with examples for Claude, Cursor, VS Code, Kiro, and other clients, plus a Docker path. However, static calibration caps setup at 15 when there is no real CI or committed test evidence, and the docs mention environment issues such as uvx ENOENT. I therefore assign 13.