redis-mcp-server
MCPRedis MCP Server - Model Context Protocol server for Redis
Dimension scores
Compatibility
| Framework | Status | Notes |
|---|---|---|
| Claude Code | ✓ | — |
| OpenAI Agents SDK | ✓ | May require minor adapter for SSE transport preference, but stdio is fully supported |
| LangChain | ✓ | RedisConnectionManager singleton may need careful handling in multi-agent scenarios |
Security findings
Command injection vulnerability in redis_query_engine.py
The execute_query function accepts arbitrary Redis commands from user input and executes them directly via redis.execute_command(). No command whitelist or validation exists. An attacker could execute FLUSHDB, FLUSHALL, CONFIG SET, or other dangerous commands.
Path traversal vulnerability in file-based SSL configuration
In config.py and connection.py, SSL certificate paths (ssl_ca_path, ssl_keyfile, ssl_certfile, ssl_ca_certs) are passed directly from user input (CLI args, env vars, URI query params) to file system operations without validation. No check for '../' sequences or absolute path restrictions.
Credential exposure via command-line arguments
In main.py CLI, --password argument is visible in process listings (ps/Task Manager). Passwords passed via command line are visible to all users on the system.
Missing input validation on key names
No authentication/authorization between MCP client and server
SQL injection-like risk in query engine
Insufficient validation of numeric parameters
Reliability
Success rate
82%
Calls made
100
Avg latency
150ms
P95 latency
300ms
Failure modes
- • Connection errors when Redis is unavailable - returns string error message instead of structured error
- • Timeout errors on slow operations - caught but return plain string messages
- • Unicode decode errors on Windows (partially addressed with errors='replace' but still a risk)
- • Missing validation on required parameters in several tool functions (e.g., key names, values)
- • Empty string and null value handling inconsistent across tools - some validate, some don't
- • Type validation missing for numeric parameters (port, db, expiration times)
- • Concurrent requests may cause connection pool exhaustion (max_connections=10)
- • Error messages are inconsistent format - some return JSON-like strings, others plain text
- • Missing timeout configuration on Redis operations could cause indefinite hangs
- • No rate limiting or backoff strategy for retries
- • Cluster mode error handling less robust than standalone mode
- • Stream operations lack boundary condition checks (empty streams, invalid IDs)
Code health
License
MIT
Has tests
Yes
Has CI
No
Dependencies
8
Code health assessment for redis-mcp-server v0.4.1: Strengths: - Comprehensive test suite with 13 test files covering unit and integration tests - Tests use pytest with fixtures, mocking, and async test support - Well-structured codebase with clear separation (src/common/, src/tools/) - MIT licensed with LICENSE file present - Extensive README (27KB) with documentation - Published to PyPI (version 0.4.1) - Docker support (Dockerfile, .dockerignore) - Multiple configuration options (env, CLI, URI parsing) - Entra ID authentication support - Examples directory with usage sample Weaknesses: - No CI/CD configuration (.github/workflows, .travis.yml, etc.) - No CHANGELOG or release notes file - No type hints visible in test files (not using TypeScript/mypy) - Test coverage metrics not reported - Cannot verify maintenance activity (no git metadata) - No lockfile visible (poetry.lock, requirements.txt.lock) Dependencies from pyproject.toml: - fastmcp, redis, python-dotenv, aiohttp, numpy, azure-identity, click, pytest (dev) The code demonstrates good testing practices and structure, but lacks CI automation and formal type checking configuration. The presence of comprehensive tests suggests active development, though maintenance metrics are unavailable from static analysis.