Skip to main content
Glama

memory_relate

Record a directed typed relation between two stored capsules, using kinds like supersedes, blocks, or part_of to express how they interrelate.

Instructions

Record ONE directed, typed relation edge from --kind--> to. Closed kinds: supersedes (from replaces to), derived_from (from was materialized out of to), witnesses (from is evidence attesting to — the ATTESTED to, when a blocks-participant, becomes DONE in memory_digest's blocks-dag: proof-carrying CLOSURE that leaves ready/blocked and stops gating dependents yet STAYS recallable — distinct from supersede's REPLACEMENT and forget's DESTRUCTION), blocks (from blocks to — feeds memory_digest's blocks-dag ready/blocked/done projection; cycles are detected there, fail-closed with the concrete cycle — repair = supersede, forget, OR witness a member), falsifies (from contradicts capsule to — the target becomes recall-INELIGIBLE, its bytes untouched and still served by memory_get/list; it is NOT a dag input), proposes (from PROPOSES to replace to — b2 staged review; NAVIGATIONAL only: no dag/ready/done effect and no recall-exclusion effect, and never auto-converted to supersedes), part_of (from is a member of container to — pure membership; NEVER a dag input, so it is byte-inert to the blocks-dag; to MUST be a capsule persisted as kind 'epic' or 'task' — classify the container first), grounded_in (from — the child task/epic/plan node — hangs off parent to; the planning-plane anchor surfaced by memory_digest's mission section, NEVER a dag input). Endpoints: to is ALWAYS a stored capsule; from is a stored capsule too — EXCEPT falsifies, whose from may instead be a stored OUTCOME record id (out- from memory_outcome), i.e. an observed outcome falsifying a claim (capsule→capsule falsifies is also allowed). Edges are readable back on memory_get's relations list (and memory_export / the memory_digest relations count). Both endpoints must be stored (tombstoned still counts — edges are history); self-relations are rejected. Re-recording an edge is an idempotent no-op keeping the first timestamp, answered with already_recorded: true (a fresh write answers false). Recording a falsifies edge is the ONLY way to fence a capsule from recall this way — an outcome record alone never does. Every edge recorded here carries origin 'manual' — a caller decision the machine NEVER auto-reverses; only the stale-import mechanism's own origin='import' supersedes edges can be machine-reversed on re-import (memory_get shows origin on import edges; first write wins on replay). Audited.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesTarget endpoint, a stored capsule id.
fromYesSource endpoint (`from --kind--> to`), a stored capsule id.
kindYesThe edge kind (closed set).
Behavior4/5

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

With no annotations, the description carries full burden. It discloses idempotent behavior, origin marking, and constraints (both endpoints stored, self-relations rejected). It explains that only 'falsifies' fences recall, and edges are history. It does not mention auth or rate limits, but covers key behavioral traits.

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

Conciseness3/5

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

The description is lengthy and dense, packing many details. While front-loaded with purpose, it could be trimmed for conciseness without losing essential information. Some redundancy exists across kind descriptions.

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?

Given the tool's complexity (9 relation kinds, unique behaviors per kind), the description is remarkably complete. It explains each kind, constraints, idempotency, origin field, and links to memory_digest. No output schema, but response fields are mentioned. Perfectly adequate for an agent to use the tool correctly.

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% (3 params). The description adds significant meaning beyond the schema: detailed definitions for each relation kind, constraints on endpoints, and idempotent behavior. This enriches the agent's understanding of how to use the parameters correctly.

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?

The description clearly states the tool's purpose: 'Record ONE directed, typed relation edge from --kind--> to.' It specifies the action (record a relation edge) and the resource (relation edges between capsules). With multiple relation kinds detailed, it distinguishes itself from sibling tools like memory_forget or memory_get.

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?

The description provides explicit context on when to use each relation kind, e.g., 'falsifies' is the only way to fence a capsule from recall. It also mentions idempotency and constraints (self-relations rejected). However, it does not directly compare to sibling tools, but the distinct purpose makes it clear.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/menot-you/n-memory'

If you have feedback or need assistance with the MCP directory API, please join our Discord server