Persistent memory for AI agents — FastAPI + SQLite + sqlite-vec, with optional PostgreSQL
Zikra presents a moderately functional MCP server with 22 well-named tools covering memory/knowledge management, prompt storage, and logging operations. Tool naming follows strong verb_noun conventions (search, save, get, list, delete, promote), and all tools have descriptions. However, parameter descriptions are inconsistent, many required and optional parameters lack explicit descriptions or validation hints. Output schemas are not documented in the source code provided. Error handling is minimal; tools do not indicate what errors may occur, what is retryable, or how agents should recover. Security considerations (permission gates, scope declarations) are mentioned in code (ROLE_PERMISSIONS, auth checks) but not surfaced in tool definitions themselves. The server uses HTTP transport (Streamable HTTP via FastAPI) which is current and appropriate.
Generate a new access token
Permanently delete a memory by UUID or title. Admin role required.
Get architecture diagram or description for a project
Get contextual information about a project, including recent memories and stats
Fetch a memory by title or ID. If project is omitted, searches across all projects (matches zikra_search behavior).
Fetch a saved prompt by name
Output schemas not documented. No tool returns documented output structure, LLMs cannot predict response fields or chain results to downstream tools.
Parameter descriptions are inconsistent and sparse. Many parameters (e.g., 'id', 'module', 'state', 'status') lack descriptions explaining their purpose, valid range, or format. zikra_create_token has no input description at all. This forces LLMs to infer intent from parameter names alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | 2026-07-28+ | v2 |
Return the database schema and table definitions
Get synchronization state for a project or module
Get help information about Zikra commands
Generate a hygiene report of the memory database
List all saved prompts, optionally filtered by project
List saved requirements, optionally filtered by project or status
Log an error or failure event
Log a completed prompt run with token usage
Get change history for a module or component
Promote a requirement to a decision or other type
Save a decision record (memory_type=decision)
Save a new memory or knowledge entry
Save a prompt template for later retrieval
Save a project requirement (memory_type=requirement)
Search memories using hybrid semantic + keyword search
Set synchronization state for a project or module
Error handling not surfaced. No tool describes what errors may occur, whether they are retryable, or what guidance to offer the agent. zikra_delete_memory requires 'Admin role' but does not surface this as a permission requirement in the description. Similar auth gates exist but are not documented in tool definitions.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are not declared. The source shows tools marked as READ_ONLY, WRITE, and DESTRUCTIVE in comments, but these are not encoded in the tool definitions via the MCP protocol's toolAnnotations feature.
Pagination not explicitly documented. zikra_list_requirements, zikra_list_prompts, zikra_module_history accept 'limit' parameters but do not document whether they support offset/cursor, what the max limit is, or whether results are capped. LLMs cannot reason about fetching all items or handling large result sets.
Mutually exclusive parameters not documented. zikra_delete_memory and zikra_get_memory accept both 'id' and 'title', but do not clarify whether both, either, or one is required. zikra_promote_requirement similarly has 'id' and 'title' without dependency documentation.
zikra_create_token has no parameters and minimal description ('Generate a new access token'). It is unclear what scope, expiration, or identifying info (e.g., runner, project) the token covers. LLMs cannot determine when to call this or what token to expect.
Scope declarations missing. Tools enforce permission checks (ROLE_PERMISSIONS in code) but tool definitions do not declare required scopes (e.g., 'admin:delete', 'write:memory'). Agents cannot be configured with least-privilege scopes.