Loading ToolBench
A personal knowledge graph system that stores memories, entities, and relationships with vector search capabilities and synthesis features
nram demonstrates solid foundational quality with well-structured tool definitions, comprehensive parameter schemas, and thoughtful descriptions that guide LLM usage. All 5 tools have explicit names, descriptions, input schemas, and clear parameter definitions. However, several tools lack complete output schema documentation, some descriptions could be more concise and action-oriented, and error handling guidance is minimal. The server shows mature thinking about tool composition (separate read/write operations, pagination support) but falls short of A-grade polish in consistency and completeness across dimensions.
Return what nram knows about who the user is: their persona / self-knowledge (identity, background, preferences, relationships, ongoing personal context), ordered most-defining first (by how central each fact's entities are, then how often it has surfaced, then recency). Call this on demand when you need to understand the user, before personalizing work, making assumptions about them, or when the task hinges on their preferences or background. You do NOT need to load it every session: ordinary recall already surfaces relevant about_me facts by association.
Ask a question and get one synthesized answer over your stored memories, with the source memories it drew on. Unlike recall (which returns a ranked list), ask runs the retrieval for you and writes a single grounded answer with footnote citations ([1], [2], …) that map to the returned sources (each source carries its citation number). Omit project for a wide synthesis across all of your projects (plus global and about_me); pass a project slug to scope to that project plus global and about_me. Single-shot: each call is one question, not a conversation. Costs a model call, so prefer recall for simple lookups and use ask when you want the answer composed for you. The confidence returned with the answer is a grounding signal, not a correctness score: it reports how strongly the cited sources match the query, so a high value does not mean the answer is right.
Delete memories that are outdated, incorrect, or superseded. Soft-deletes by default. Project must already exist.
Output schema documentation incomplete. Tools declare return types via mcp.WithRawOutputSchema() but source code lacks visible definition of expected response structures for downstream tool chaining. ask(), graph(), and forget() responses are not documented in provided source.
Error handling and recovery guidance absent. Tools return mcp.NewToolResultError() for error cases, but do not provide actionable next steps (e.g., 'user not found: try search_users() first'). This violates recovery-guide pattern.
ask() and graph() descriptions are verbose (100+ chars intro before core semantics). LLM token cost increases; clarity decreases. Baseline for A+ is 50-200 chars per description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2025-06-18+ | v2 |
Explore entity relationships in the knowledge graph. Use to discover how people, technologies, and concepts connect. Reach for it whenever recall is noisy or misses a fact you expect to exist: query the key concept, follow its relationships to the entity that should hold the fact, then fetch the source memory behind that relationship (its source_memory id) with get, instead of re-running recall with reworded prose.
List all available projects with slugs and descriptions, paginated (default limit 50, max 200). ALWAYS call this before store to check for an existing project; an unknown slug on store auto-creates a new project. The reserved projects 'global' (world-knowledge) and 'about_me' (the user's self-knowledge) are auto-created for every user, carry nram-managed descriptions, and cannot be deleted.
forget() description lacks explicit statement that deletion is irreversible. For destructive operations, the description must say 'deletes permanently' or 'removes data'. Currently states 'soft-deletes by default' but LLM reading the signature alone may not grasp the implications.
graph() depth and min_weight parameters lack constraint examples. Description should state 'default 2, max 5' and 'range 0.0-1.0' explicitly, not rely on prose 'server-capped' and 'default 0.1'. Parameter constraints prevent LLM from passing invalid values.
Pagination boundary conditions not documented. list_projects and about_me support limit and offset, but descriptions do not specify: What happens if offset > total? Are results sorted? What is the sort order? This matters for reliable pagination.