MCP stdio server for NocturnusAI — agent reasoning, memory lifecycle, and token-optimized context windows for AI applications
NocturnusAI MCP server exhibits significant definition quality gaps. Tool descriptions are present but generic and lack LLM-optimization. Parameter schemas exist but are minimally documented. Critical issues: (1) Most tool descriptions are under 20 chars or lack actionable context ('Assert a fact', 'Query NocturnusAI'). (2) Parameters have type definitions but descriptions are sparse or missing context about expected formats, constraints, and when to use each. (3) No documented output schemas are visible in source code. (4) Error handling and recovery guidance are absent. (5) Tools lack clarity on scope isolation and rule inference semantics. The server defines 9 tools across two code samples (Python SDK and demo files); tool definitions appear inferred from descriptions rather than explicitly registered with full schema validation. This caps individual tool scores at 50 maximum where source visibility is limited.
Query NocturnusAI using logical inference. Applies rules for multi-step deductive reasoning. Use ?-prefixed variables (like ?x, ?who) for unknowns.
Get the most relevant facts from NocturnusAI ranked by salience (recency, frequency, priority). Use to populate context.
Retract a fact from NocturnusAI. Derived knowledge is automatically retracted via truth maintenance.
Teach a logical rule to NocturnusAI. Rules are Horn clauses: if all body conditions are true, the head is derived.
Assert a fact into the NocturnusAI knowledge base. Facts are predicate-argument structures like 'likes(alice, bob)'. Use this to store knowledge.
Run logical inference over the knowledge base. Use this to derive facts that aren't stored directly but can be inferred from rules.
No documented output schemas visible in source code. LLMs cannot plan downstream tool calls or extract required data without knowing what fields each tool returns.
Parameter descriptions lack actionable constraints, ranges, and format guidance. E.g., max_facts and min_salience have no documented bounds; predicate and args have no examples or validation rules; no guidance on ?-variable syntax beyond mention.
Tool descriptions are generic, domain-specific, or under 50 characters. E.g., 'Assert a fact' (12 chars), 'Query NocturnusAI' (16 chars), 'Retract a fact' (14 chars) fail to guide LLM tool selection or explain when to use each tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Search the knowledge base for facts matching a pattern. Use '?x', '?who', etc. as wildcards in the args array.
Store a fact in the agent's persistent knowledge base. Use this whenever the user tells you something worth remembering.
Retrieve the most relevant facts from the knowledge base based on salience. Call this at the start of a session to load context.
Semantic ambiguity across multiple tools. nocturnusai_ask and recall both search facts; nocturnusai_context and working_memory both retrieve salience-ranked facts; nocturnusai_tell and remember both assert facts. LLMs will conflate these and waste reasoning cycles.
No error handling or recovery guidance. Tools have no documented failure modes, retryability, or what to do when queries fail, predicates don't exist, or inference times out.
Scope parameter is optional and undocumented on all tools. LLMs have no guidance on what scope isolation means, when to set it, what happens if omitted, or whether cross-scope queries are allowed.
No pagination or result limit guidance for tools that return fact lists (nocturnusai_context, recall, working_memory). No documented maximum results, cursor/offset support, or guidance on what happens when result sets are large.
Tool definitions appear inferred from descriptions rather than explicitly registered with full schema validation in source code. Cannot verify actual MCP schema registration or runtime behavior.