Skip to main content
Glama
Cloto-dev

CPersona

Official
by Cloto-dev

declare_associations

Idempotent

Declare associative memory: register entities with aliases and subject-predicate-object relations, stored verbatim, with retraction by ID.

Instructions

Declare associative memory after the fact: entities with aliases, and subject–predicate–object relations, recorded verbatim and walked by reconstruct. The server extracts nothing and infers nothing — coverage is exactly what was declared. Names, aliases and predicates are compared after normalization (NFKC, case-folded, whitespace collapsed), so two declarations that normalize alike are one entity. An alias resolves to at most one entity per scope; a second claim on it is dropped. anchor_ref names the record (mem:<id> / ep:<id>) the declaration is evidenced by: every entity named is recorded as mentioned by it and every relation carries it. A relation's endpoint is an entity name (registered if new) or a record ref of this agent. Malformed items are reported in dropped and skipped; nothing else in the call is refused for them. retract removes relations by id and mentions by {entity, ref} — the only way a declaration leaves the store. Response: {ok, result:'declared', entities:[{id, name, created}], mentions, relations:[ids], dropped:[{item, reason}], retracted?:{relations, mentions}}. Under pause_persistence nothing is written (result:'skipped', persisted:false).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
channelNoMemory channel the declaration belongs to. Default: '' (shared).
retractNoDeclarations to remove: {relations: [relation ids], mentions: [{entity: <entity id>, ref: 'mem:<id>'}]}. Only this agent's rows are touched.
agent_idYesAgent identifier
anchor_refNoThe record this declaration is evidenced by: 'mem:<id>' or 'ep:<id>' of this agent. Optional.
project_idNoProject the declaration belongs to. Optional — omit or pass '' for the global pool. v2.5.1: pass '@auto' to resolve this agent's default from the server's operating context (the resolution is echoed as resolved_project_id; an unmapped agent yields operating_context_warning). bug-186: resolution requires a configured operating context. With none — the default, and equally the outcome of a sidecar that fails to parse — the sentinel is NOT resolved: it is stored and filtered as the literal project_id '@auto', resolved_project_id echoes '@auto', and no warning is raised. Read resolved_project_id before relying on the resolution.
session_keyNoOpaque session identity you declare: a partition hint, not authentication and not a data filter. Selects which no-persist pause applies to this call. Omit to share one bucket with every caller that omits it. Full text on recall.
associationsNoAssociative memory to declare alongside this call: entities the text mentions, with their aliases, and subject–predicate–object relations. Stored verbatim; the server extracts nothing and infers nothing. On store, the stored memory is recorded as mentioning every entity named here and anchors every relation. Malformed items are reported in the response's associations.dropped and skipped; the memory is stored regardless. Optional.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.5.12

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond the annotations by disclosing normalization rules, alias conflict resolution, dropped-item handling, pause_persistence behavior, retract semantics, and the exact response shape. It provides rich behavioral detail without contradicting the readOnlyHint, idempotentHint, or destructiveHint annotations.

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?

The description is dense and front-loaded with the core purpose, but the long single-paragraph format makes it harder to scan. It is appropriately detailed for a complex tool with nested parameters and no output schema, though it could benefit from structured breaks or bullet points.

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, nested schema, and absence of an output schema, the description is remarkably complete. It covers response fields, failure handling, retraction, persistence-pause behavior, edge cases around project_id resolution, and interaction with reconstruct. Nothing essential is missing.

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

Parameters5/5

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

Although the schema already covers 100% of parameters, the description adds substantial meaning: anchor_ref semantics, relation endpoint rules, alias deduplication, project_id '@auto' resolution caveats, session_key partitioning, and retract scope. This is far beyond the baseline expected for fully documented schemas.

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 opens with a specific verb and resource: 'Declare associative memory after the fact' and immediately defines entities with aliases and subject–predicate–object relations. It also distinguishes itself from sibling tools by stating that the server 'extracts nothing and infers nothing' and that coverage is exactly what was declared, making its role clear.

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 gives clear context: declarations are evidenced by an anchor_ref, stored verbatim, and later walked by reconstruct, while retract is the only way to remove them. It does not explicitly name alternative tools or exclusion conditions, but the intended usage is evident from the behavior described.

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