Loading ToolBench
Personal Knowledge Base & Memory Layer for AI Agents. Save, search, and retrieve memories, documents, and contextual knowledge across any LLM.
Memwyre presents a foundational MCP server with 10 tools, but exhibits significant quality gaps. Tool names follow verb-noun convention adequately (e.g., save_memory, search_memwyre, delete_memory), meeting basic naming standards. However, the critical blocker is that NO input schemas are visible in the provided source code. The mcp.json manifest lists tools with names and brief descriptions only, no parameter definitions, types, or constraints. This is a hard failure against the definition quality rubric. Descriptions are present but minimal (15-45 characters), falling short of the 50-200 character LLM-optimized baseline. Without visible schemas and with underdeveloped descriptions, agents cannot reliably infer parameter intent or validate input. The server implements HTTP transport (Streamable HTTP declared in mcp.json), satisfying protocol transport requirements, but the tool definitions themselves lack the rigor expected of production-grade agent tooling.
Delete a memory or document by ID.
Generate a prompt with retrieved context from your memories.
Get a list of all tags used in your knowledge base.
Retrieve the full content of a specific document by ID.
Get list of pending memories in the Inbox.
List recent memories and documents.
Save a new memory snippet to the Memwyre Vault. Use this tool when the user explicitly asks you to 'remember' something, 'save' a note, or when you encounter important information that should be persisted for future reference.
No input schemas visible for any tool. mcp.json lists tool names and descriptions only, with no parameter definitions, types, or constraints.
Descriptions are underdeveloped (15-45 characters, average ~27). Baseline for LLM-optimized descriptions is 50-200 characters. Current descriptions lack context on WHEN to use each tool, WHAT dependencies exist, or HOW to interpret results. For example, 'List recent memories and documents' does not explain pagination behavior, filtering, or result structure.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
Find memories created within a specific date range.
Semantic search across your saved memories, documents, and notes.
Update the content of an existing memory.
No documented output schemas. The rubric requires tools to document what fields to expect in responses so agents can plan downstream calls and extract data. save_memory likely returns a memory ID or record; list_memories likely returns an array of memory objects. Without visible response schemas, agents cannot chain tool calls reliably.
Destructive tools (delete_memory) lack explicit confirmation or dry-run support. The rubric requires: 'Irreversible operations (delete, send, publish) should support a dry-run or confirmation step.' No mention of confirmation workflow in description.
No visible error handling guidance in tool descriptions. The rubric requires: 'Error responses must tell the LLM what to do next.' For example, search_memwyre does not document what happens if no results are found, or how agents should retry if the API is rate-limited.
Parameter descriptions missing. save_memory lists parameters (text, source, tags, workspace_name) but mcp.json provides no type information, descriptions, or constraints. Agents cannot determine whether 'tags' is an array of strings, enum, or something else. The rule 'Every parameter needs a description explaining what it controls' is unmet.