Loading ToolBench
Local-first intent, evidence, and provenance for Codex, Claude Code, Cursor, Gemini CLI, and MCP agents.
Pathmark has 23 tools with consistent naming (verb_noun pattern) and descriptions present for all. However, schemas are inferred from parameter lists rather than explicitly visible in source code. Input parameters have type annotations and descriptions, but output schemas are not documented. Error handling is minimal, no recovery guidance or actionable error messages visible. Tool composition is reasonable (each tool has a single responsibility), but several tools lack depth in parameter constraints (enums, ranges, format specs). The server targets a specialized domain (memory/evidence management) with domain-appropriate naming, but generic descriptions like 'Search memory records by query text' lack LLM-optimized context about when to use this tool vs. recall_memory.
Approve a pending conclusion and move it to active memory.
Query memory with natural language question and receive synthesized answer.
Generate comprehensive audit report on memory quality, recall coverage, and synthesis metrics.
Create a backup of the memory store.
Interactive chat with memory context and transparent evidence tracking.
Optimize memory store by removing duplicates and consolidating records.
Consolidate raw evidence records into synthesized conclusions.
Output schemas not documented. Tools like search_memory, recall_memory, and ask_memory return results but no schema is visible describing the structure of returned records, pagination fields, or evidence metadata. LLMs cannot plan downstream tool calls without knowing what fields to expect.
Parameter constraints missing. Numeric parameters (limit, days, charLimit) lack min/max bounds. The 'format' parameter in export_memory lists options as description text ('jsonl, json, csv') rather than an enum constraint. LLMs cannot validate inputs and may pass invalid values.
Destructive operations lack confirmation or dry-run. purge_memory and compact_memory (with dryRun=false) can permanently delete data, but no confirmation step or recovery guidance is documented. Agents may accidentally destroy memory without safeguards.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Create a conclusion with optional evidence references and approval workflow.
Validate memory store integrity and report health metrics.
Export memory records in portable format.
Retrieve contextual memory summary for a query with optional namespace scoping.
Generate a compact snapshot of active memory state.
List all approved conclusions with optional tag filtering.
List conclusions pending approval review.
Permanently delete a memory record.
Provide relevance feedback on recalled memory records to improve precision metrics.
Recall memory records with semantic search, optional exact ID pinning, and transparent evidence metadata.
Reject a pending conclusion and remove it from consideration.
Save a memory record with optional tags, namespace, and source attribution.
Search memory records by query text with optional tag filtering.
Retrieve chronological trace of session activity with optional output inclusion.
Mark a memory record as superseded by a newer record.
Update an existing memory record with new content.
Ambiguous tool selection. search_memory, recall_memory, ask_memory, and chat all retrieve memory but differ in semantics (keyword vs. semantic, natural language vs. structured). Descriptions do not explain when to use each. LLMs will guess and pick the wrong tool.
Error handling not visible. No recovery guidance, error classification, or actionable messages documented. If a tool fails (e.g., invalid namespace, memory not found), the LLM has no guidance on what to do next.