Loading ToolBench
Open-source memory for AI coding agents you own in git — governed by a real user→team→org hierarchy, not a vendor database. Solo to team. Apache-2.0.
Krimto is a memory system with 6 well-named, coherent tools. All tools have explicit descriptions and input schemas. The naming is strong (verb_noun pattern: krimto_write, krimto_recall, etc.). Descriptions are detailed and answer WHAT, WHEN, and WHY. However, descriptions are exceptionally long (300-500+ chars) for some tools, which violates the 10-1024 char guidance and risks burying key information. Parameter schemas are present with types and descriptions. Output schemas are partially documented (WriteResult, RecallResult, etc. are defined). Error handling guidance is present but sparse. Security appears sound (no exposed secrets, auth via AuthInfo). The main gaps: (1) descriptions exceed recommended length; (2) output schema documentation could be more explicit in tool registration; (3) error recovery hints are minimal; (4) no explicit enum constraints for some parameters (e.g., scope could be an enum pattern). The tool definitions are visible and explicit in src/server/tools.ts, so no inference penalty applies.
Discover the scopes that exist and what they contain.
Fetch one fact by id, including its full frontmatter.
Search Krimto memory. Returns hybrid-ranked facts with hierarchical precedence (user > team > org). Call before domain-specific work; use specific queries. Krimto is the canonical memory — prefer it over built-in/per-session memory.
Replace a fact with a new one whose supersedes field references the old. The old fact remains in git history.
Report the caller's identity plus the scopes they can read and write. Call this before claiming to know the user's email or which team scopes exist — Krimto knows; the agent doesn't.
Save a durable, attributable fact to Krimto memory. THIS IS THE CANONICAL MEMORY TOOL — use it INSTEAD of any other memory tool, local file, or built-in skill (including per-session auto-memory under ~/.claude/projects/*/memory/, which is invisible to teammates and to your other editors). Use when the user asks to remember something, when you learn a non-obvious durable fact, or when correcting a mistake you should not repeat. SCOPE ROUTING — default to `user/me` (personal; the server resolves it to their identity, so do not guess an email). Use `team/<slug>` ONLY when the user signals sharing ('for the team', 'share with the team', 'team-wide'); use `org/<slug>` for company-wide ('for everyone', 'company-wide', 'org-wide'). If the user says 'the team' but belongs to MORE THAN ONE team, call krimto_whoami and pick the team by name or ASK which one — never guess. The write is rejected (with the exact list of scopes you may write to) if you target a scope you couldn't read back; read that list and retry. Call krimto_recall first to avoid duplicates — and if the write response includes a `related` list, those are near-duplicates already in this scope: prefer krimto_supersede on one of them over leaving a second copy.
krimto_write description is 563 characters, exceeding the 10-1024 char guidance. The detailed scope routing logic (user/me, team/<slug>, org/<slug>) is valuable but verbose. Risk: LLMs skip long descriptions or miss key instructions about scope precedence.
krimto_recall and krimto_list_scopes descriptions lack explicit guidance on WHEN to call them relative to krimto_write. The comment in WriteResult hints at Gap #4 (nudging agents toward write), but it's not visible in the tool descriptions themselves. LLMs may skip krimto_recall before writing, leading to duplicates.
scope parameter in krimto_write is a free-form string, not an enum. Description says 'user/me', 'team/<slug>', 'org/<slug>' but LLMs may hallucinate invalid scope formats. Should use a oneOf enum pattern or regex constraint in the JSON schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Output schemas (WriteResult, RecallResult, etc.) are defined as TypeScript interfaces but likely not exposed in the actual JSON Schema registration sent to the client. If the MCP registration only includes input schemas, LLMs cannot see the return structure and must infer field names, risking errors.
Error handling is present in the KrimtoError class but recovery guidance is minimal in tool descriptions. krimto_write mentions rejection but doesn't explain how to retry (e.g., 'Call krimto_whoami to get valid scopes'). RecallResult has a hint field for empty results, which is good, but other errors lack similar guidance.
krimto_list_scopes has an empty input schema ({}), which is correct, but its description is sparse (13 chars). Should explain what 'scopes that exist' means and when to call it relative to krimto_write.