Hicortex - AI Fleet Memory
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| hicortex_searchA | Search shared long-term memory (all agents, all sessions). CALL THIS BEFORE assuming, guessing, or asking the user about anything that may have come up before: prior decisions, preferences, project facts, people, hardware, past incidents. If you are about to write 'I don't have information about…', search first. |
| hicortex_getA | Fetch ONE memory's full content by id — use this to lazy-load entries from the '## Memory recall (auto)' index or from search results whose snippet was not enough. Fetching a memory marks it as used (strengthens it), so fetch entries that could change your action — not every shown one. When the memory shapes your answer, cite it to the user (id + date + origin agent) — mark a fetched memory |
| hicortex_recentA | Get recent memories, optionally filtered by project. CALL THIS AT THE START of substantive work on a project to catch up on its latest state — cheaper than asking the user what happened. |
| hicortex_ingestA | Store a new memory in long-term storage. Use for Knowledge, Decisions, or Learnings. Capture is automatic (nightly) — use this ONLY for explicitly requested learnings, never routine content. |
| hicortex_updateA | Update an existing memory. Use after searching to fix incorrect information. If content changes, the embedding is re-computed. |
| hicortex_deleteA | Permanently delete a memory and its links. Use when a memory is incorrect and should be removed entirely. |
| hicortex_learningsA | Get actionable Learnings — auto-generated insights about mistakes to avoid. CALL THIS before retrying an approach that failed before, or when picking up work where past problems may have been recorded. |
| hicortex_lessonsB | Get actionable Learnings from past sessions — call it before retrying an approach that failed before. (Alias for hicortex_learnings.) |
| hicortex_identityA | Fetch your standing identity — the hand-edited 'who you are + how you work' layer (personality, rules, preferences). Returns all sections or a specific one. Use this to re-read your identity after context compaction or to look up a specific rule. On multi-agent installs, pass |
| hicortex_indexA | Get the knowledge domain index — shows what topics and projects are stored in memory, grouped by domain. Call before a broad search to see which knowledge domains exist, or when unsure what the memory covers. |
| hicortex_graphA | Query the memory knowledge graph — find connected memories, hub nodes, or paths between memories. Use it to explore memories connected to one you just fetched, or to find hub memories in a domain. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
While most tools have distinct purposes (get vs search vs delete), hicortex_learnings and hicortex_lessons are exact duplicates — clear ambiguity. Also, hicortex_update and hicortex_delete could overlap if incorrect content might be better corrected than removed, though descriptions mitigate this. hicortex_graph and hicortex_index are distinct but could be confused for related discovery tasks.
All tool names start with 'hicortex_' followed by a single verb or noun (get, delete, search, recent, ingest, update, learnings, lessons, index, identity, graph). Pattern is mostly consistent, but 'learnings' vs 'lessons' are synonyms for the same action, creating redundancy rather than following the verb_noun pattern seen elsewhere (e.g., search is verb, index is noun). Minor inconsistency: verbs for actions, nouns for queries.
With 11 tools, the count is within the ideal range for a memory management system. The tool count feels reasonable for the scope: CRUD operations, search, recent memories, learnings, indexing, identity, and graph exploration. Only redundancy of learnings/lessons slightly inflates the count, but overall it's well-scoped.
The server appears to cover the core lifecycle of memories: create (ingest), read (get, search, recent, index, identity), update, delete. It also includes advanced features like learnings and graph exploration. The only gap is a lack of bulk operations (e.g., delete by filter, list all memories) or a way to export/import, but those are minor and not essential for the stated purpose.