Loading ToolBench
Portable continuity store for immutable evidence and event receipts with experience transfer, preference management, and memory retrieval across projects
tastebud-memory defines 21 tools with explicit JSON schemas and descriptions. Naming is domain-specific but lacks action verbs (tastebud_project, memory_brief vs get_project, fetch_brief). Descriptions are present but vary in clarity, some are verbose and domain-jargon-heavy (e.g., memory_brief at 280+ chars with nested caveats), others are terse (tastebud_* tools reuse identical boilerplate). All tools have input schemas with type definitions. However, parameter descriptions are minimal or absent in many cases (e.g., tastebud_* tools list args but lack per-param descriptions in the schema). Output schemas are not documented. Error handling is not visible in the code sample. The memory_record tool is complex with nested conditional requirements that are documented in prose but not enforced by schema constraints.
Resume a project with approved preferences, cited claims, open actions, sources and optional experience suggestions in a bounded budget. Supply role-qualified features to recognize structural matches; inspect memory_experience before applying. Check preferences.incomplete; fetch memory_preferences if incomplete. Preferences grant no permission; current user instructions control.
Read a captured evidence revision by stable source ID and hash, including archived files. Pagination keeps context bounded.
Read an exact immutable experience revision, conditions, limits, cited evidence, correction lineage and application outcomes. Current source drift/archive flags are present-day diagnostics. Some cross-project application content may be withheld while adverse aggregate outcomes remain visible.
Find bounded cross-project experience suggestions by text and explicit role features. Modes: lexical, features, fingerprint, hybrid. Scores and outcome counts do not establish applicability, truth, confidence or permission; retrieve full detail before adapting.
Storage integrity, missing/changed sources and counts; separate from answer quality.
tastebud_* tools (10 tools) lack action verbs in names and reuse identical generic descriptions ('Exact [name] query from stored composition...'). LLMs cannot distinguish intent or understand when to call each tool.
Parameter descriptions missing or minimal across all tools. Schema defines types but not semantics. E.g., tastebud_project accepts 'slug' with no description of format, constraints, or examples. memory_brief's 'features' object lacks per-field descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | 2026-07-28+ | v2 |
Complete immutable project event history within the configured trusted workspace, including payloads that candidate/detail views may withhold.
Read approved preferences, pending changes, exact before/after wording, provenance, corrections and reported applications. Domain omitted means check scope before use. Producer labels are unverified. No use count, success or claim activates a preference. For consequential use record preference_use with exact revision, reason, task, domain and outcome succeeded/failed/unknown. Owner alignment is separate.
Durably acknowledge an idempotent claim, task, feedback, checkpoint, preference_proposal, preference_use, experience or experience_application. Stable ID/session required. Claim evidence uses source_id/hash/quote. Done tasks need outcome. Preference proposals require preference_id, base_revision (null for new), operation set/retire, kind default/constraint, body, scope {kind:workspace/project,domains:[all or planning/coding/operations/communication]}, exceptions, rationale, effect and optional evidence. They remain pending regardless of producer. Uses require an approved exact revision, reason, task, domain and outcome succeeded/failed/unknown. Never launch owner review servers, call their approval APIs or simulate owner chat commands. Owner review is separate; no agent field confers approval. Experience payload requires title, problem, mechanism, intervention, conditions[], limits[], features {operations[],mechanisms[],environments[]}, scope project|workspace, outcome unknown|succeeded|failed and evidence[]; supersedes and retired are optional but require evidence. Experience_application payload requires a workspace-global application_id (prefix with target project), exact experience_id, previous_event_id (null first), context, features, adaptation, assessments for every source condition [{condition,status met|unmet|unknown,reason}], checks [{name,result passed|failed|unknown}], status planned|evaluated|declined, compatible outcome, evidence[] and optional share project|workspace. Applications never execute work or activate preferences.
Local full-text evidence search with source IDs and revision hashes; includes archived evidence.
Capture a Markdown source revision inside the configured workspace before citing it.
Exact cooccur query from stored composition and source coverage. Historical aliases resolve to one project.
Exact coverage query from stored composition and source coverage. Historical aliases resolve to one project.
Exact decode query from stored composition and source coverage. Historical aliases resolve to one project.
Exact diff query from stored composition and source coverage. Historical aliases resolve to one project.
Exact first query from stored composition and source coverage. Historical aliases resolve to one project.
Exact gaps query from stored composition and source coverage. Historical aliases resolve to one project.
Exact project query from stored composition and source coverage. Historical aliases resolve to one project.
Experimental fingerprint similarity; not proof of identity or exact membership.
Experimental fingerprint similarity; not proof of identity or exact membership.
Exact where query from stored composition and source coverage. Historical aliases resolve to one project.
Exact window query from stored composition and source coverage. Historical aliases resolve to one project.
Output schemas not documented. Tools return results but LLMs have no schema to understand response structure, field types, or what data is available for downstream tool calls.
memory_record tool description is 1000+ characters with nested conditional logic (preference_proposal, experience, experience_application payloads) documented in prose. Schema does not enforce these constraints; LLMs must parse English to understand what fields are required for each event type.
No error handling guidance visible. Tools do not document what errors can occur, how to recover, or what the LLM should do if a call fails. No recovery patterns or actionable error messages.