MCP Server for simulating prefix caching and KV state reuse using a radix tree data structure to manage cached token prefixes and calculate TTFT latency reductions
Two tools with minimal descriptions (both under 100 chars) and schemas present but sparse. insert_prefix and lookup_prompt lack parameter descriptions entirely, the schema shows property names but no 'description' fields for 'prompt' or 'kv_cache_id'. No output schema documented. No error handling guidance. Tool names are verb-noun but descriptions are vague about when/why to use them. No mention of side effects, prerequisites, or recovery paths. Schemas are valid JSON Schema but lack the richness needed for LLM reasoning.
Insert system prompt or template prefix into the radix cache
Check prefix cache hit and compute TTFT latency reduction
Parameter descriptions missing entirely. 'prompt' and 'kv_cache_id' in insert_prefix have no description fields in the schema. LLMs cannot infer what format 'prompt' expects (raw text? tokenized? max length?) or what 'kv_cache_id' should contain (UUID? arbitrary string? uniqueness requirement?).
Tool descriptions are too brief (35 - 40 chars) and lack context. 'Insert system prompt or template prefix into the radix cache' does not explain when to call this vs lookup_prompt, what happens to the cache, or whether the operation is idempotent. 'Check prefix cache hit and compute TTFT latency reduction' does not explain what a 'hit' means or how the result should be used.
No output schema documented. The code returns JSON with fields like 'status', 'total_tokens', 'cached_tokens', 'hit_ratio', 'estimated_ttft_reduction', 'is_full_cache_hit' but the tool definitions do not declare these. LLMs cannot plan downstream actions or extract the right fields without knowing the response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
No error handling or recovery guidance. The code catches exceptions and returns a generic error dict, but does not categorize errors (retryable vs fatal) or suggest next steps. An LLM receiving 'error: KeyError' has no idea whether to retry, ask the user, or abandon the task.
Tool names lack clarity about side effects. 'insert_prefix' modifies state (caches data) but the description does not say 'This operation is idempotent' or 'Overwrites existing cache entry with the same kv_cache_id'. Agents need to know which calls are safe to retry.