Skip to main content
Glama
Sign In
AICortex

AICortex

by IkarusMK
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Memory write

memory_write
Destructive

Saves a durable, typed memory to the persistent brain, requiring user, feedback, project, or reference classification so facts stay organized and replaceable by title.

Instructions

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 review date) · reference (pointers to resources/URLs/IDs). An untyped memory is REFUSED so the brain stays sorted. Only store DURABLE facts (not session chatter), nothing already in code/git, and NEVER secrets (those go to the vault: secret_set via integration_call). Writing the same title again REPLACES that memory (read it first and fold the old content in); the dedup hint flags related titles to merge.

Input Schema

NameRequiredDescriptionDefault
tagsNoComma-separated, e.g. "garden, mqtt"
typeYesRequired — one of the four types above
scopeNoMemory area: "shared" (default) or "users/<id>"; a person limited to their own area stays there anywayshared
titleYesShort title; it names the memory
reviewNoYYYY-MM-DD: from then on cortex_start lists it as due for review
sourceNoWhere the fact comes from, e.g. a URL; default "session"
contentYesThe fact itself, in Markdown
projectNoProject this fact belongs to, e.g. "Birdhouse"; empty = general
expected_versionNoThe version you read with memory_read; refused if it changed since. 0 = don't check

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.4
    • addedInput schema / properties / content / description
      Added value: +"The fact itself, in Markdown"
    • addedInput schema / properties / title / description
      Added value: +"Short title; it names the memory"
    • addedInput schema / properties / type / description
      Added value: +"Required — one of the four types above"
  2. Changed6 schema fields changedv0.1.2
    • addedInput schema / properties / expected_version / description
      Added value: +"The version you read with memory_read; refused if it changed since. 0 = don't check"
    • addedInput schema / properties / project / description
      Added value: +"Project this fact belongs to, e.g. \"Birdhouse\"; empty = general"
    • addedInput schema / properties / review / description
      Added value: +"YYYY-MM-DD: from then on cortex_start lists it as due for review"
    • addedInput schema / properties / scope / description
      Added value: +"Memory area: \"shared\" (default) or \"users/<id>\"; a person limited to their own area stays there anyway"
    • addedInput schema / properties / source / description
      Added value: +"Where the fact comes from, e.g. a URL; default \"session\""
    • addedInput schema / properties / tags / description
      Added value: +"Comma-separated, e.g. \"garden, mqtt\""
  3. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description explains exactly why: writing the same title REPLACES the existing memory. It further discloses that untyped memories are REFUSED and that a dedup hint surfaces related titles to merge — behavior not derivable from the schema or annotations. Minor gap: it doesn't state whether replacement can be undone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense and front-loaded, with the required-type rule stated before the exclusions. Heavy capitalization and parenthetical asides make it slightly noisy, but nearly every clause carries actionable content rather than restating the name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nine-parameter mutation tool with an output schema and full annotation coverage, the description covers the remaining unknowns an agent needs: the type taxonomy, the refusal on missing type, the destructive title-overwrite, the dedup hint, and where secrets belong instead.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline would be 3, but the description adds real meaning beyond it: it defines what each of the four type values is for (user/feedback/project/reference) and gives a usage rule for review on project memories. The title/overwrite interaction is also clarified in prose rather than left to the field description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ("Save a durable, TYPED memory") and immediately distinguishes itself from the read/search siblings by emphasizing typed durability and write-back. The four enumerated types make the tool's identity unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use criteria (durable facts only, not session chatter, nothing already in code/git) and an explicit routing rule for the excluded case: secrets go to the vault via secret_set through integration_call. It also instructs the agent to read before rewriting the same title, pointing at memory_read.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools