Loading ToolBench
A Model Context Protocol server for Redis operations, providing tools to interact with Redis databases through MCP
Redis MCP server has basic tool definitions with names and descriptions, but critical gaps in schema completeness, parameter documentation, and error handling. All 4 tools lack input parameter type definitions in the visible schema, parameters are documented in descriptions only, not in formal JSON Schema. Descriptions are present but generic (10-60 chars), below the 50-200 char baseline for LLM-optimized tools. No output schemas documented. Error handling returns plain strings without recovery guidance. Tool composition is reasonable (each does one thing), but parameter naming inconsistencies (e.g., 'keys' param in get() vs 'key' in set()) and lack of enum constraints invite LLM confusion.
Delete one or multiple keys from Redis
Get value from Redis by key
List Redis keys matching a pattern
Set a Redis key-value pair with optional expiration time
Input schemas lack formal type definitions. Parameters documented only in descriptions, not in JSON Schema 'type' and 'properties' fields.
Parameter naming inconsistency: get() uses 'keys' but set() uses 'key'; delete() accepts both string and array for 'keys' without enum constraint. LLMs will conflate these.
No output schemas documented. Callers cannot predict response structure (plain string vs JSON object). Breaks downstream tool chaining.
Error responses are plain strings ('Error parsing JSON arguments: ...') without recovery guidance. LLMs cannot determine if error is retryable or user-fixable.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | <=2025-11-25 | v2 |
Descriptions too short (10-60 chars vs 50-200 baseline). 'Get value from Redis by key' lacks context on when to use vs list(), what happens on miss, or expected return format.