AICortex
Server 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.
AICortex is the user's persistent memory, skill library and tool hub, shared by all their AI apps and agents. At the start of a conversation call cortex_start (pass the project you are working on and the task, if known): it returns who the user is, how they want you to work, and the project's notes, open tasks and last session.
While working:
Look things up before assuming: memory_search(query, project), skill_search(query).
Save durable facts with memory_write (type: user, feedback, project or reference; add project=...). Not chat chatter, never secrets.
Before you stop, save a checkpoint with session_save(summary, next_steps, project) so another app or agent can continue.
Multi-stage work (e.g. a software change) can follow a playbook: playbook_start, then playbook_submit each stage's artifact. A person approves every stage; never approve for them.
Rules:
Reply in the user's language. AICortex itself speaks English only so every model understands it.
Secrets live in the vault and are used server-side. Never ask for them in chat and never write them into memory.
Confirm with the user before outbound, physical or destructive actions (sending mail, posting, printing, deleting).
More tools (devices, services, files, mail, calendars, printing, scheduling, admin) are found with integration_search("what you want to do") and run with integration_call(name, arguments). cortex_catalog lists everything registered; guide explains all tools in detail.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| cortex_startA | Call this first in every conversation. Returns a briefing: who the user is
and how they want you to work; for |
| bootstrapA | Start-of-conversation briefing, identical to cortex_start: who the user is, how they want you to work and the project's notes, tasks and last session. Kept so project instructions that say "call bootstrap" keep working; new setups call cortex_start. |
| memory_writeA | Save a durable, TYPED memory and write it back to the brain.
type (REQUIRED) = one of: user (who the user is / preferences) ·
feedback (how you should work — corrections & confirmed approaches) ·
project (ongoing work, goals, status — give it a |
| memory_readA | Read a memory's full content and version by its name — find the name with memory_search. An unknown name returns "No memory named …". |
| memory_searchA | Find memories by words (any order); best matches first — a hit in the title counts most, then tags/project, then the text. Returns name, title and a snippet; memory_read gives the full text. |
| skill_searchA | Find skills for a task: up to 10 lines "name — description", best first (a word in the name counts most, then description, tags, text); no match says so. Call this before specialized work, then skill_load the best match. |
| skill_loadA | Load a skill's full instructions (its whole SKILL.md) by name — find the name with skill_search. An unknown name, or a skill outside your allowed set, gets a message saying so. |
| task_listA | List the tasks on the shared agent board — work handed between agents — oldest first, every match (id, status, owner, title). Check it before adding or claiming one (task_add / task_claim via integration_call). |
| session_saveA | Append a checkpoint to a work session so another LLM/device can resume it — for handing over work in progress; durable facts belong in memory_write. Returns the session id. Old sessions auto-expire after SESSION_RETENTION_DAYS. |
| integration_searchA | Find a tool beyond the core set — devices, services, files, mail, calendars, printing, scanning, SSH, webhooks, scheduling, playbooks, agents and administration. Returns matches best first, each with its parameters (* = required); no match says so. Run one with integration_call. For how-to instructions use skill_search, for stored facts memory_search. Example: integration_search("print a PDF on the office printer"). |
| integration_callA | Run a tool found with integration_search and return its result unchanged — its own errors too; a name you may not call is refused with a pointer to integration_search. Same permissions as calling the tool directly: one that changes or deletes data does so here as well, so confirm such steps as you would there. Example: integration_call(name="print_document", arguments={"printer": "office", "file": "scan.pdf"}). |
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
The search/read/load pairs are carefully differentiated: memory_search returns snippets then memory_read full text, skill_search finds names then skill_load loads SKILL.md, integration_search finds tools then integration_call runs them. The exception is bootstrap vs cortex_start, which are documented as functionally identical, giving an agent a genuine coin-flip on the first call. The remaining tools (memory_write, session_save, task_list) have clearly separate purposes.
Nine of eleven tools follow a clean resource_verb snake_case pattern (memory_read, skill_load, integration_call, session_save, task_list). bootstrap is a bare noun and cortex_start inverts the word order (prefix + verb), but neither is cryptic and both are readable in context.
Eleven tools is well within a healthy range for a personal-assistant/brain server spanning memory, skills, integrations, sessions and tasks. Each core tool earns its place by covering a distinct capability surface rather than duplicating another. Extra operations (task_add, task_claim, secret_set) are correctly pushed behind integration_call instead of bloating the direct surface.
Memory, skills and integrations each have a coherent find-then-act lifecycle, and write-replaces-title covers memory updates. Two minor asymmetries remain: there is no memory delete/forget tool, and session_save has no matching session_read (resume relies on cortex_start surfacing the last session). Task creation and claiming are reachable only indirectly via integration_call, which is workable but less discoverable than task_list being first-class.