Loading ToolBench
MCP server to interact with redis server, aws memory DB, etc for caching or other use-cases where in-memory and key-value based storage is appropriate
This Redis MCP server provides 10 tools with basic parameter schemas and descriptions, but falls short of production quality on several critical dimensions. Tools are named clearly with action verbs (get_, set_, delete_, list_, push_, add_) and descriptions are present for all tools and parameters. However, schemas are incomplete, most tools lack full type information in the visible code, output schemas are undocumented, and error handling is minimal. The server uses string return types for all tools rather than structured responses, forcing LLMs to parse unstructured text. No tool annotations (readOnlyHint, destructiveHint) are present despite clear risk levels. Parameters like 'field' in hash_get lack constraints or guidance. No pagination is implemented for potentially large result sets (list_keys, redis_info, hgetall). Security is basic, no permission checks, no rate limiting, and no audit trail. The codebase is functional but would not pass production code review.
Delete a Redis key
Get value for a Redis key
Get hash fields
Set multiple hash fields
Push values to a Redis list
Get a range of values from a Redis list
Publish a message to a Redis channel
Add members to a Redis set
All tools return plain strings instead of structured JSON responses. Responses like 'Successfully set key "mykey"' or 'Error: ...' require LLMs to parse unstructured text. No documented output schemas.
No tool annotations present despite clear risk levels. hash_set, delete_key, list_push, publish_message, set_add are WRITE or DESTRUCTIVE operations, they should be annotated with destructiveHint or idempotentHint to guide LLM decisions on retry safety.
No pagination support. Resources like 'redis://keys/{pattern}' via redis_client.keys() and 'redis://info' can return unbounded results. Large result sets will blow context windows and degrade LLM reasoning.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 53 | - | v1 |
Get all members of a Redis set
Set value for a Redis key
Error handling is minimal. Errors are returned as plain strings (e.g., 'Error: connection refused'). No recovery guidance, no error classification, no actionable next steps for the LLM.
Parameter 'field' in hash_get has description 'Optional specific field to get (if None, gets all fields)' but lacks constraints or guidance on when each mode is appropriate. Type annotation shows string, but behavior changes on None.
No permission checks or access control. Any agent with access to this server can read, write, delete, and publish to any Redis key/channel without restrictions.
No rate limiting. A runaway agent could generate thousands of Redis calls per minute without guards, overwhelming the Redis instance or downstream subscribers.
Destructive operations (delete_key, hash_set with overwrite, set_add) lack confirmation steps. No dry-run or approval pattern, an LLM mistake triggers immediate data loss.
No audit trail. Tool calls are not logged with user/agent identity, parameters, timestamp, or outcome. Compliance and incident response are impossible.
The 'side' parameter in list_push accepts string ('left' or 'right') with no enum constraint. LLMs may pass invalid values like 'head', 'tail', or 'front'. Should be constrained to an enum.