A typed graph-based knowledge management system served over MCP. Stores persistent memory as plain markdown files with YAML frontmatter, queryable by keyword and graph structure. Supports full-text search, node creation/linking, and BFS traversal with bi-temporal validity filtering.
Litopys demonstrates solid tool design with well-structured schemas and clear descriptions. All 5 tools have explicit input schemas with typed parameters and enums where appropriate. Descriptions are substantive (100-250 chars), explaining both purpose and use cases. The knowledge graph domain is well-represented through litopys_search, litopys_get, litopys_related, and mutation tools (litopys_create, litopys_link). However, output schemas are not documented in the source code provided, and error handling guidance is minimal. Tool naming follows verb_noun convention (search, get, create, link, related) appropriately. Parameter descriptions are generally good but lack some actionable constraints (e.g., what happens if a node already exists in litopys_create, or retry guidance on failures).
Create a new node in the knowledge graph. Fails if the id already exists.
Get a node by id or alias, optionally including incident edges.
Add a relation from source node to target node. No-op if the relation already exists.
BFS traversal from a node. Returns a subgraph of connected nodes and edges up to the given depth.
Full-text search over the Litopys knowledge graph. Returns ranked hits by name, alias, body, and tags. The top hits arrive with their depth-1 relations already attached (`neighbours`), so a follow-up litopys_related call is only needed to walk deeper than one hop.
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., what fields does litopys_search return? Does it include node IDs for chaining to litopys_get?). This violates pattern:tool and pattern:response-shaper.
litopys_create lacks error guidance. Description says 'Fails if the id already exists' but does not explain what error the LLM should expect or how to recover (e.g., 'If you get a conflict error, try litopys_get to check the existing node'). Violates pattern:recovery-guide.
litopys_create and litopys_link are write operations but lack confirmation or dry-run support. Agents can accidentally create duplicate nodes or malformed relations without a chance to review. Violates pattern:confirmation-request.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Parameter 'as_of' in litopys_search and litopys_related lacks actionable constraint description. Format is stated as 'ISO date (YYYY-MM-DD)' but no guidance on what happens if the date is invalid, in the future, or before the graph's earliest event. Violates review:param-validation-rules.
litopys_link description does not clarify idempotency. It says 'No-op if the relation already exists' but does not state whether the response indicates success, no-op, or error. LLMs need explicit idempotency guarantees to plan retries safely. Violates pattern:idempotent-operation.