Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This Redis MCP server has 19 tools with basic descriptions but significant quality gaps. Naming is verb-based (get_, set_, list_, etc.) which is correct, but parameter schemas lack depth. Most tools have descriptions (10-150 chars), but many are too generic (e.g., 'Get data by key', 'Create key'). Parameter descriptions exist but are minimal. Output schemas are not documented, responses are inferred from code inspection but not formally declared in tool definitions. Error handling is present in the code but not surfaced in tool descriptions to guide LLM recovery. The server lacks tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk categories (READ_ONLY, WRITE, DESTRUCTIVE). No pagination guidance in the list_keys tool, and no dry-run or confirmation mechanism for destructive operations. The implementation is functional but does not meet production-grade tool quality standards.
Tool descriptions are too generic and lack LLM guidance. Most descriptions are 10 - 50 characters (e.g., 'Get data by key', 'Create key') and do not explain when to use the tool, what it returns, or dependencies. Descriptions should be 50 - 200 characters and answer: WHAT, WHEN, and RESULT.
Output schemas are not documented in tool definitions. The code returns structured results (e.g., {success: true, value: ...} for get_data), but this contract is not declared in the tool schema, forcing LLMs to infer response structure from context.
Expand tool descriptions to 50 - 200 characters. For each, answer: (1) What does it do? (2) When should the LLM call it instead of a similar tool? (3) What does it return? Example: 'get_data: Retrieve a value from Redis by key. Returns the value and its type (string, list, set, hash, zset). Use this after list_keys to fetch a specific key.'
Add output schema documentation to each tool. Include field names, types, and examples. Example for get_data: 'Returns: {success: boolean, value: any, type: string (string|list|set|hash|zset), ttl: number|null}'.
Implement tool annotations for all tools. For example: get_data should have readOnlyHint=true; delete_data and drop_key should have destructiveHint=true; set_data and create_key should have idempotentHint=false (or true if keys are unique).
Add a confirmation step for destructive operations. Introduce a confirm_delete_key(key) tool that returns {keyExists: boolean, willDelete: boolean, confirmation_token: string}. Then delete_key must provide the token. Or use MRTR (Multi-Round-Trip Request) to ask for user confirmation before executing.
Enhance parameter descriptions with constraints and enums. For set_data 'type' parameter, use: 'Data type for the key (default: string). Values: string (simple text/binary), list (ordered sequence), set (unique values), hash (field-value pairs), zset (sorted set by score). Choose based on use case: string for small values, list for sequences, set for unique items, hash for objects, zset for leaderboards.'
Add error guidance to tool descriptions. For each tool, include a line like: 'Errors: If the key does not exist, returns {success: false, error: "Key not found"}. Check exists_key first if unsure.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite clear risk classifications in metadata (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE). This prevents agents from understanding operation safety.
Destructive operations (delete_data, drop_key, clear_operation_logs) lack confirmation or dry-run support. Agents can permanently delete data without verification, risking data loss.
Parameter descriptions lack detail on constraints and formats. For example, set_data 'type' parameter describes it as 'Data type: string, list, set, hash, zset (default: string)' but does not explain what each type does or when to use each. Parameter descriptions should specify valid values, ranges, formats, and dependencies.
Error handling in tool descriptions is absent. The code throws informative errors (e.g., 'Failed to get data: ...'), but tool descriptions do not guide LLMs on what to do when errors occur (retry, ask user, investigate). Error descriptions should state the error type and recovery action.
list_keys lacks pagination guidance in the description. While it accepts limit and offset parameters, the description does not explain pagination behavior, recommend result limits, or advise on large result handling.
Permission control is implemented (ALLOW_INSERT, ALLOW_UPDATE, ALLOW_DELETE, ALLOW_CREATE, ALLOW_DROP environment variables) but not exposed in tool descriptions. Tools should declare what permissions they require so agents know which tools are available.
set_dataupdate_datadelete_datacreate_keydrop_key
Document pagination behavior for list_keys. Expand description: 'List keys matching a pattern with pagination. Returns up to limit keys (default 100, max 1000). Use offset for pagination. Returns {keys: [string], total: number, hasMore: boolean}. Large result sets should use limit=100 and iterate through pages.'
Declare permission requirements in tool descriptions. Add a line to set_data, create_key, update_data, delete_data, drop_key: 'Requires: Set environment variable ALLOW_INSERT=true (or ALLOW_UPDATE, ALLOW_CREATE, ALLOW_DELETE) on the server before calling. If not permitted, returns {success: false, error: "Operation not allowed by server policy"}.'
Accept natural identifiers for keys. Currently, all tools require exact Redis key names. Consider adding a key_alias or key_pattern tool to resolve human-friendly names (e.g., 'user:john' → actual key stored in Redis). Document this in tool descriptions.
Add a dry_run or simulation parameter to destructive tools (delete_data, drop_key). When true, return {wouldDelete: true, key: '...', size: bytes} without executing. This prevents accidental data loss.