A caching skill for storing and retrieving key-value pairs using Vercel KV Redis
This MCP server has one tool (set_cache) with critical definition quality gaps. The tool has a basic description and input schema, but lacks output schema documentation, error handling guidance, and comprehensive parameter descriptions. The description is adequate but minimal. No evidence of authentication, validation, or recovery patterns. Tool naming is acceptable but the implementation is incomplete for production use.
Store a key-value pair in the cache
Missing output schema documentation. Tool returns {"cache_status": "..."} but this structure is not formally documented in the tool definition. LLMs cannot plan downstream tool calls or validate responses.
No error handling or recovery guidance. Tool description states 'Store a key-value pair in the cache' but does not explain what happens on failure, when to retry, or how to diagnose issues. No error classification (retryable vs fatal).
Parameter descriptions are minimal. 'key' is described as 'The cache key' and 'value' as 'The value to store', these restate the parameter names without explaining constraints, format, or valid ranges.
No parameter constraints or validation rules. No maximum length for 'key' or 'value'. No enum, pattern, or format constraints. LLMs may pass absurdly large strings or invalid characters without guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
Missing TTL, expiration, or cache behavior documentation. Tool description does not explain when cached values expire, whether keys can be overwritten, or storage limits. These are critical for agent planning.
No complementary retrieval tool. This server only exposes set_cache but not get_cache or retrieve_cache. A cache without retrieval is unusable, agents cannot read values they just stored.
No authentication, permission checks, or audit logging. Tool accepts any key/value without authorization. No mechanism to prevent unauthorized agents from overwriting shared cache entries.
Tool implementation is a stub returning a hardcoded status. The client.py set_cache() method does not actually interact with Vercel KV or Redis, it just returns mock success. Cannot validate against real backend behavior.