mcp-server-duckdb
MCPA DuckDB MCP server
Dimension scores
Compatibility
| Framework | Status | Notes |
|---|---|---|
| Claude Code | ✓ | — |
| OpenAI Agents SDK | ✓ | SSE transport not explicitly supported, relies on stdio which may require adapter |
| LangChain | ✓ | Tool returns string representation of results rather than structured data, may need parsing wrapper |
Security findings
SQL Injection vulnerability in query tool
In server.py line 127-128, the query tool accepts raw SQL strings with no validation or parameterization: `results = db.execute_query(arguments['query'])`. The execute_query method in line 62 passes user input directly to DuckDB: `connection.execute(query, parameters).fetchall()`. An attacker can execute arbitrary SQL including ATTACH DATABASE, COPY TO, or other DuckDB commands to exfiltrate data or modify the filesystem.
Path traversal vulnerability in db-path argument
In config.py lines 30-34, the --db-path argument accepts any Path with no validation: `parser.add_argument('--db-path', type=Path, help='Path to DuckDB database file', required=True)`. An attacker controlling the configuration could specify paths like '../../../etc/passwd' or use symlinks to access arbitrary filesystem locations. The server creates directories (server.py line 24) and database files without sanitizing the path.
Verbose error messages expose internal details
In server.py lines 131-134, exceptions are caught and returned with full error details: `return [types.TextContent(type='text', text=f'Database error: {str(e)}')]` and `text=f'Error: {str(e)}'`. This exposes internal database structure, file paths, and potentially sensitive information from DuckDB error messages to the LLM client.
No authentication or authorization mechanism
The server implements no authentication system. Any client that can connect to the stdio interface has full access to execute arbitrary SQL queries (in non-readonly mode) or read all data (in readonly mode). The server.py file has no checks on caller identity or permissions.
No input length validation on SQL queries
Readonly mode bypass through DuckDB extensions
Database lock issues with keep_connection mode
Reliability
Success rate
82%
Calls made
100
Avg latency
45ms
P95 latency
120ms
Failure modes
- • Missing arguments dict causes generic 'Missing arguments' ValueError without specifics
- • Invalid SQL syntax returns duckdb.Error with technical message - parseable but not user-friendly
- • Empty query string accepted by handler but may fail in DuckDB execution layer
- • No input validation on query parameter - accepts any type, relies on DuckDB to fail
- • Connection errors during keep_connection mode could leave connection in bad state
- • Type mismatches in query parameters not validated before execution
- • Very long queries (edge case) have no timeout protection
- • Concurrent requests in keep_connection mode may cause database locking without retry logic
- • Unicode/special characters in queries passed directly to DuckDB without sanitization checks
- • Database file permission errors during initialization cause unhandled exceptions
Code health
License
MIT
Has tests
Yes
Has CI
No
Dependencies
3
Well-maintained MCP server with good fundamentals. Has comprehensive tests covering readonly modes, database creation, and error cases. Clear documentation with installation instructions and configuration examples. MIT licensed and published to PyPI (v1.1.0). Uses modern Python tooling (uv, ruff linter configured). Missing: CI/CD configuration, type hints (no mypy/TypeScript), changelog, and git history metadata unavailable for commit analysis. Dependencies are minimal and appropriate (duckdb, mcp). Test files show good coverage of edge cases. Code is clean and well-structured with dataclasses and proper error handling. Loses points for lack of CI, type annotations, and observable maintenance metrics.