AI Coding CLI with Persistent Spiral Memory – MCP server providing context management and tool orchestration for AI-assisted development
HelixMind exposes 5 tools for spiral context management. Tool naming follows a consistent spiral_* prefix pattern (verb+noun structure), which is good. However, definitions suffer from incomplete parameter schemas, missing parameter descriptions, and vague tool descriptions that lack actionable context for LLM selection. The server provides basic descriptions but falls short of production-grade clarity. Parameter descriptions are either missing entirely or generic. Error handling is not evident from the provided code. No tool annotations (readOnlyHint/destructiveHint/idempotentHint) are present despite tools having clear risk profiles.
Trigger manual compaction. Compresses old context nodes and optionally deletes very old ones in aggressive mode.
Query the spiral context store. Returns proactively assembled context across Focus (L1), Association (L2), and Periphery (L3) levels.
Manually create a relation between two context nodes. Relations are used to proactively inject associated context.
Show the current state of the spiral context store: node counts per level, edge counts, storage size, and embedding status.
Store new context in the spiral. Automatically generates embeddings, detects relations to existing context, and assigns the appropriate spiral level.
Missing parameter descriptions and constraints across all tools. Parameters like 'relationshipType', 'type' (in spiral_store), and 'limit' lack detailed descriptions explaining valid values, formats, and constraints. This forces LLMs to guess at valid inputs.
spiral_compact does not explicitly warn that it is a destructive operation that deletes data irreversibly. Description lacks 'modifies state' language. No confirmation step or dry-run option is mentioned for this high-risk tool.
No output schemas documented for any tool. LLMs cannot predict what fields to extract or how to chain results into downstream calls. For example, spiral_context and spiral_store should document their response structures.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | 1.27.1+ | v1 |
Missing tool annotations despite clear risk profiles. spiral_store and spiral_relate are WRITE operations; spiral_compact is DESTRUCTIVE. MCP tool annotations (readOnlyHint, destructiveHint, idempotentHint) should declare these characteristics so agents and clients can enforce policies.
'spiral_relate' uses a free-form 'relationshipType' string parameter with no enum or validation. Invites hallucinated invalid relationship types. Should define valid types (e.g., references, depends_on, related_to, duplicates, related_to_parent).
Parameter 'limit' in spiral_context has no min/max bounds. LLMs could pass absurdly large values (e.g., limit=999999) causing performance degradation. Should specify range like 1-100.
No error handling guidance provided. What happens if a node ID doesn't exist? If embeddings fail? If aggressive compact deletes too much? Responses should guide LLM recovery (retry, fallback, ask user). Currently tool definitions provide no recovery hints.