MCP server for managing memories using Google Vertex AI Vector Search with FastAPI backend and Next.js frontend
Three tools with minimal descriptions (10-50 chars) and no visible input schemas in the provided code. Tool names follow verb_noun convention (add_memories, search_memory, list_memories) but descriptions lack context on WHEN to use each tool, prerequisites, or return structure. No parameter descriptions visible. No error handling guidance. No output schema documentation. Code snippet cuts off mid-implementation, preventing full schema verification.
Add new memories to the user's memory
List all memories in the user's memory
Search the user's memory for memories that match the query
No input schemas visible for any tool. Cannot verify parameter types, constraints, or descriptions. Code snippet terminates mid-implementation.
Tool descriptions are 10-50 characters, below the 194-char baseline. Lack WHAT/WHEN/WHY context. 'Add new memories to the user's memory' does not explain when to call this vs search_memory, what format 'text' accepts, or what the tool returns.
No output schema documented. LLMs cannot plan downstream calls or extract required fields (e.g., memory_id for subsequent operations). No pagination support visible for list_memories despite potential for large result sets.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 34 | 2026-07-28+ | v2 |
No error handling guidance. If add_memories fails due to invalid text format or quota limits, LLM receives no recovery path. No distinction between retryable vs user-fixable errors.
add_memories is a WRITE operation but lacks idempotency guarantee or confirmation step. Agents retrying on ambiguous failures risk duplicate memory entries.