MCP server that exposes Redis-compatible tools for querying and manipulating a mnemos data store. Provides generic command execution and curated tools for key operations, scanning, and server introspection.
Six tools with complete JSON schemas and basic descriptions. However, descriptions are minimal (10-50 chars), parameter descriptions lack detail on constraints/formats, and no output schemas are documented. The redis_command tool is a dangerous escape hatch that bypasses safety. Error handling is present but generic. No tool annotations (readOnlyHint/destructiveHint). Naming is clear (verb_noun pattern) but descriptions do not explain WHEN to use each tool or what downstream tools need. Schemas are present but sparse, no enums, ranges, or format constraints. This is a functional but under-documented Redis wrapper.
Describe a key: its type, size, and TTL if any. Returns null when the key does not exist.
Read a string key. Returns null when it does not exist.
Run any command against the server and return its reply as JSON. The escape hatch: use it for anything the other tools do not cover.
Walk the whole keyspace with SCAN and return the matching keys. Glob patterns are supported.
Introspect the server: its version, uptime, memory use, and the keyspace.
Write a string key, optionally with a TTL.
redis_command is an unsafe escape hatch that bypasses all safety constraints. It accepts arbitrary Redis commands (FLUSHDB, SHUTDOWN, etc.) with no validation, permission checks, or audit trail. This violates the principle of least privilege and enables catastrophic data loss.
Descriptions are too brief (10 - 50 chars) and lack actionable context. They do not explain WHEN to use each tool, what it returns, or how it chains with others. E.g., 'Read a string key' does not say what happens on miss (null vs error) or whether the tool is safe to retry.
No output schemas documented. LLMs cannot plan downstream calls without knowing what fields to expect. E.g., does get() return {value: string} or {value: string, ttl: int}? Does scan_keys() return {keys: [string], cursor: string}?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Parameter descriptions lack constraints. 'count' in scan_keys says 'Default 100, capped at 10000' in description but no min/max in schema. 'pattern' in scan_keys has no format guidance (glob syntax not explained). LLMs cannot validate inputs without explicit constraints.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe reads from destructive writes without explicit hints. set() and redis_command() are destructive but unmarked; get(), describe_key(), scan_keys(), server_info() are read-only but unmarked.