Recall facts, semantic memories, and error-fix procedures in one query, with current facts first, replacing three separate searches.
Unified recall across all memory types at once (facts + memories + procedures) for one query. Current facts first, then semantic memories, then matching error->fix procedures. One call instead of three separate searches.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max per silo | |
| query | Yes | What to recall |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden; it usefully discloses result ordering (current facts, then semantic memories, then error->fix procedures), which is real behavior beyond the schema. It says nothing about read-only safety, permissions, pagination, or result size limits, leaving notable gaps for a no-annotation tool.
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?
Three short sentences with zero filler; scope and the core differentiator ('one call instead of three') are front-loaded. Every clause carries information.
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?
No output schema exists, and the description partially compensates by describing the ordering of returned silos, which is the key thing an agent needs to interpret results. It is nearly complete for a two-parameter recall tool, missing only return-shape and safety details.
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 coverage is 100% and both parameters ('query' and 'limit') are already documented there, so the description only adds the framing 'for one query' and the notion of per-silo limiting. No format, syntax, or default behavior is added beyond the schema, making baseline 3 appropriate.
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?
States a specific verb (recall) and resource (all memory types: facts + memories + procedures), and explicitly frames itself as the union of three searches, which distinguishes it from siblings like mind_recall and mind_search. An agent can tell what this returns without opening the schema.
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 phrase 'One call instead of three separate searches' clearly signals when to prefer this tool over narrower search calls. However, it never names the actual alternative tools (mind_search, mind_recall, mind_fact_query) or states any when-not condition, so routing is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.