Momento MCP server implementation providing cache and topic operations
Momento MCP has clear tool names (get, set, list-caches, create-cache, delete-cache, publish) that follow verb_noun conventions. All 6 tools have descriptions and visible Zod schemas with typed parameters. However, descriptions are minimal (10-60 chars), lacking context on WHEN to use each tool or what happens on error. Parameter descriptions exist but are generic. Output schemas are not documented, responses are hardcoded text strings without structured field definitions. Error handling returns status strings but no recovery guidance. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels (READ_ONLY, WRITE, DESTRUCTIVE). Missing idempotency guidance for retry-safe operations.
Creates a new cache
Deletes a cache and all contained values from your Momento account
get a key-value pair from the cache
Lists all cache names in your Momento account
publish a value to a topic
set a key-value pair in the cache
Descriptions are too brief (10-60 chars) and lack context. 'get a key-value pair from the cache' does not explain when to use get vs list-caches, what happens on miss, or error recovery. Baseline for A-grade tools is 50-200 chars with WHEN/WHY guidance.
Output schemas are not documented. Tools return hardcoded text responses (e.g., 'Status: HIT\nValue: ...') without structured field definitions. LLMs cannot parse or chain results reliably. Responses should declare fields like {status: string, value?: string, error?: string}.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels declared in metadata (READ_ONLY, WRITE, DESTRUCTIVE). Agents cannot infer which tools are safe to retry or have side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Error responses lack recovery guidance. 'Status: ERROR\nDetails: ...' tells the agent nothing about whether to retry, ask the user, or abort. Should categorize errors (retryable, user-fixable, fatal) and suggest next steps.
delete-cache is destructive but lacks confirmation or dry-run support. Agents can permanently delete caches without a safety gate. Should implement confirmation_request pattern or require explicit confirmation parameter.