Skip to main content
Glama

Kosmodrom

by ai.kosmodrom
OverviewDiscussionsAdmin

memory_create

Saves a confirmed fact, rule or recipe as an agent memory record when the user asks to keep knowledge for future agent work; secrets only at the user's direct request. The record starts personal and unverified: it applies to the token owner's agents at once, and a moderator can make it shared. level is the scope: company (Git, cloud, CI), user (personal preferences), project (stands, addresses, project infrastructure) or repository (conventions, tests, code pitfalls).

Input Schema

NameRequiredDescriptionDefault
jobsNoJobs the record is for; at least one for job and request, none for always.
loadYesalways - delivered with any work, short; job - with the jobs in `jobs` (prevention, silent pitfalls); request - only in the `memory` index, read by ID (symptom diagnostics, narrow areas).
textYesOne topic, 1.5-3 thousand characters (max 4,000), in the language of the workspace data: rules and facts with reasons. Author and date are record fields, no "Source" line needed.
levelYes
titleYes"<area> · <situation or symptom>: <what's inside>", up to 200 characters, in the language of the workspace data; agents judge relevance by the title in the memory index.
projectIDNoProject ID, for level = project.
productIDsNoFor level = project: the products where the record is delivered. Products of its own project: only in them (none of them listed - in all products of the project); products of other projects: in them too.
repositoryIDNoRepository ID, for level = repository.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / productIDs
      Added value: +{
+  "description": "For level = project: the products where the record is delivered. Products of its own project: only in them (none of them listed - in all products of the project); products of other projects: in them too.",
+  "items": {
+    "format": "uuid",
+    "type": "string"
+  },
+  "maxItems": 50,
+  "type": "array"
+}
    • changedInput schema / properties / title / description
      Previous value: -"\"<area> · <situation or symptom>: <what's inside>\", up to 200 characters, in the language of the workspace data; agents judge relevance by it, and agents doing other kinds of work see it only up to \": \"."New value: +"\"<area> · <situation or symptom>: <what's inside>\", up to 200 characters, in the language of the workspace data; agents judge relevance by the title in the memory index."
  2. Changed2 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • changedInput schema / properties / title / description
      Previous value: -"\"<area> · <situation or symptom>: <what's inside>\", up to 200 characters, in the language of the workspace data; agents judge relevance by it."New value: +"\"<area> · <situation or symptom>: <what's inside>\", up to 200 characters, in the language of the workspace data; agents judge relevance by it, and agents doing other kinds of work see it only up to \": \"."
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations confirm this is a non-read-only, non-destructive, closed-world write, and the description adds genuinely new lifecycle semantics: the record starts personal and unverified, is immediately visible to the token owner's agents, and a moderator can promote it to shared. It also flags the secrets caution. It stops short of describing authorization requirements or failure modes.

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?

Two sentences, front-loaded with the action and the trigger, then the scope semantics. Dense but every clause carries information; the second sentence is long yet justified by four distinct scope values.

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

Completeness4/5

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

For an 8-parameter mutation tool with no output schema, the description covers purpose, trigger, visibility lifecycle and scope semantics, which is most of what an agent needs. Remaining gaps — the conditional level/ID relationships and duplicate-handling behavior — are covered by the schema or left implicit.

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 already 88%, so the baseline is 3, but the description adds real meaning by spelling out each `level` value (company/user/project/repository with examples) even though the schema leaves `level` undescribed. It does not expand on projectID/productIDs/repositoryID conditionality beyond what the schema states.

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?

States a specific verb and resource — 'Saves a confirmed fact, rule or recipe as an agent memory record' — and scopes it to persistent knowledge for future agent work. This clearly separates it from memory_read/memory_list/memory_update among the siblings.

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

Usage Guidelines4/5

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

Gives a clear trigger condition ('when the user asks to keep knowledge for future agent work') plus an important restriction ('secrets only at the user's direct request'). It does not name alternatives such as memory_update or create_rules, so the agent must infer when updating an existing record is preferable to creating one.

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

All Kosmodrom toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources