Loading ToolBench
MCP-native, local-first memory search and distillation for AI conversations
RecallNest demonstrates good schema discipline with explicit input definitions for all 11 tools, detailed parameter descriptions, and thoughtful use of constraints (enums, min/max lengths). However, descriptions vary significantly in depth, some are excellent (60-80 chars, action-oriented), while others are verbose (200+ chars) and could be more LLM-optimized. Tool naming follows verb_noun convention well ('store_*', 'set_reminder', 'promote_memory'). Output schemas are not documented in the source provided, and error handling strategies are not visible. Security considerations (secrets in parameters, permission gates) are not evident. Composition is strong, tools are single-responsibility and designed to chain naturally (e.g., promote_memory links evidence to durable memory). Overall: solid parameter engineering, room for description refinement and output documentation.
Extract memory-worthy items from a conversation turn using lightweight heuristics (zero LLM calls). Detects preferences, identity facts, decisions, corrections, explicit memory instructions, and workflow patterns. Items that pass salience filtering are stored as durable memories. Use this when you want to analyze a block of conversation text and automatically capture any signals worth remembering.
List or inspect conflict candidates where promoted evidence disagrees with existing durable memory. Read-only. Use when reviewing pending conflicts before resolution.
Promote an evidence memory into durable memory with an authority upgrade. Side effect: creates a new durable entry linked to the source evidence. Use when a transcript snippet or imported artifact contains a fact worth keeping across windows.
Resolve a conflict candidate by keeping existing, accepting incoming, or merging texts. Side effect: updates conflict status and may modify durable memory. Use when list_conflicts shows open conflicts that need a decision.
Set a prospective memory reminder that auto-triggers during future search_memory calls when the trigger keywords match. Side effect: stores a reminder entry. Use when you need a future nudge tied to a specific context.
Output schemas not documented. Tools like store_memory, promote_memory, and workflow_observe return results but no schema documentation is visible in source. LLMs cannot predict downstream tool chain compatibility or structure responses without documented output types.
Description lengths inconsistent. Several tools have verbose descriptions (200+ chars: 'workflow_observe' at ~300 chars, 'store_memory' triggers field at 150+ chars in description). Rubric baseline: 194 chars avg, p90=392. While within range, descriptions should prioritize conciseness for LLM token efficiency. Descriptions like set_reminder (110 chars) are more optimal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Store a reusable case as durable memory. Use this when you identify a concrete problem-and-solution pair worth reusing across future windows, such as a debugging fix, continuity cleanup, migration lesson, or implementation recovery.
Store a durable memory when the user shares a stable preference, identity fact, project entity, reusable pattern, or solved case that should survive future windows. Do not use this for transient task state; use it only for memory worth keeping.
Store a reusable workflow pattern as durable memory. Use this when you identify a repeatable process worth reusing across fresh windows, such as startup continuity, debugging routines, review flows, or handoff steps.
Generate an evidence pack for a workflow primitive with recent issues, top signals, and suggested actions. Read-only. Use when investigating why a workflow is degraded and you need concrete failure examples.
Inspect workflow observation health: 7d/30d report for one workflow or dashboard of degraded workflows. Read-only. Use when checking if continuity primitives are succeeding or degrading.
Store an append-only workflow observation for self-evolution. Use this to record whether a continuity primitive or reusable workflow succeeded, failed, was corrected by the user, or was missed entirely. Optionally pass `skillId` to also bump that skill's successCount/failureCount — the canonical way to close the skill feedback loop.
Error handling guidance absent. No error responses visible in tool definitions. Pattern:recovery-guide requires error messages guide LLM toward recovery. E.g., 'scope parameter required' should include 'Format: project:name or session:id'.
Parameter dependency chains undocumented. store_memory uses 'triggers' (2-5 question phrases) only when privacyTier='memory:pivot' per comment. No schema validation visible for this conditional logic. LLMs won't understand when triggers are required vs optional.
Destructive operation confirmation missing. resolve_conflict with resolution='accept_incoming' overwrites durable memory. Pattern:confirmation-request would benefit from dry-run or explicit accept pattern (e.g., require 'confirm=true'). No evidence of pre-write confirmation.
Security context sparse. No visible permission gates, scope validation, or audit trail declaration on tools. 'scope' is a parameter (not a permission gate) on most write tools. No indication these are logged or access-controlled per pattern:audit-trail.