Skip to main content
Glama
Sign In
robo-cortex

robo-cortex

Official
by robotel-limited
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

record_memory

Store an explicit memory with validated code paths and an optional expiry date; global memories require assumptions, and dead links are rejected before writing.

Instructions

Create a memory -- the only way new memories enter the store (explicit authorship). Linked paths are validated to exist at HEAD before anything is written; a dead link is refused loudly. scope='global' memories are written to the reusable cross-project store, require non-empty assumptions, and cannot have linked paths. No inline evidence field -- call attach_evidence afterward.

valid_until (optional ISO-8601 timestamp, e.g. '2027-01-01'): marks this memory stale past that date. There is no valid_from -- a memory is valid starting from its own created_at, automatically. Omit for a memory with no expiry (the default).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "type": "<type>",
      "scope": "<scope>",
      "statement": "<statement>",
      "confidence": "<confidence>"
    },
    "name": "record_memory"
  }
}

Input Schema

NameRequiredDescriptionDefault
typeYes
pathsNo
scopeYes
statementYes
confidenceYes
assumptionsNo
lesson_fromNo
valid_untilNo
why_it_mattersNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.8.0
    • addedInput schema / properties / valid_until
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Valid Until"
+}
  2. Addedv0.7.0
  3. Removedv0.4.2
  4. First observedv0.4.1

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so well: paths are validated against HEAD before any write, dead links are refused loudly, global-scope memories require non-empty assumptions and cannot have linked paths. It also discloses the expiry model (valid_until only, no valid_from, default is no expiry), which is behavior an agent could not infer from the schema.

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?

Front-loaded with the core purpose and the write-time validation rule, then moves to scope-specific constraints and field notes. The 'There is no valid_from' explanation is slightly redundant but earns its place by preventing a common wrong-parameter assumption; overall there is little waste.

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

Completeness3/5

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

For a 9-parameter mutation tool with no annotations and no output schema, the description covers the risky parts (validation, global scope, expiry) but leaves four parameters undocumented, including two required ones. It also never indicates what a successful call returns, which matters for a creation tool an agent will likely need to reference afterward.

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

Parameters3/5

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

Schema coverage is 0%, so the description must compensate, and it only partially does: it explains paths, scope, assumptions, and valid_until semantics in useful detail. The required `type` and `confidence` parameters, plus `lesson_from` and `why_it_matters`, get no explanation at all, and with no enums declared an agent has no idea what values confidence or type accept.

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 ('Create a memory') and immediately establishes exclusivity ('the only way new memories enter the store'), which tells an agent this is the sole creation path. It also differentiates from the sibling attach_evidence by explicitly deferring evidence to that tool.

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 clear routing guidance: use this to create, then call attach_evidence afterward because there is no inline evidence field. It also flags the scope='global' path and its extra requirements. It does not state any when-not-to-use conditions or contrast with link_memories/change_status, but the creation-only framing is unambiguous.

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