Store a new memory with FastEmbed embeddings and LLM enrichment to persist useful context and improve future retrieval.
Store a new memory with FastEmbed embedding and LLM enrichment
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | fact | |
| agent | No | main | |
| content | Yes | ||
| client_id | No | Associated client/entity ID |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it 'stores' a memory, implying a write operation, but fails to mention potential side effects (e.g., whether it overwrites existing memories, any limits, or required permissions). The technical detail about FastEmbed and LLM enrichment does not address behavioral consequences for the caller.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly efficient, and front-loaded with the core action. It avoids redundancy and maintains a logical structure, though it sacrifices necessary detail for brevity. It is appropriately sized for the simplicity of the tool but could have included more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters with very low schema coverage, no output schema, and no annotations, the description is severely incomplete. It does not explain how parameters should be used, what the return value looks like, or any edge cases. An agent would have almost no guidance on how to invoke this tool correctly beyond guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only client_id has a description), and the tool description adds no parameter information at all. It does not explain the meaning or required format of 'content', 'type', or 'agent', nor does it clarify how they interact. The description completely fails to compensate for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Store a new memory') with a specific resource, and the tool name 'add_memory' aligns perfectly. The mention of FastEmbed embedding and LLM enrichment provides specific technical context that distinguishes it from siblings like search_memory or log_prediction, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for storing memories but does not explicitly state when to use it versus alternatives. Siblings like search_memory and memory_stats have distinct purposes, and an agent could infer the correct choice from the name alone, but no explicit guidance on conditions or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.