Skip to main content
Glama

memory_vector

Attach a caller-computed embedding to a capsule for semantic recall, or list stored embeddings. Pass capsule_id, embedding, and model_tag on attach.

Instructions

Attach (or LIST) a CALLER-FED embedding — the u6a semantic sidecar. nmemory computes NO embedding (zero embedder dependency, zero network): YOU compute the vector with your own model and put it here; recall's semantic lane is DORMANT until you do. PUT: pass capsule_id (its id alias is accepted) + embedding:[f32] + model_tag (the caller-declared provenance of the embedding — MANDATORY, the u6a provenance law; it names WHICH model produced these numbers so a later reader can trust/compare them). ONE EMBEDDER PER STORE, mechanically: the first attach elects the store's resident model_tag, and an attach carrying a DIFFERENT tag is refused naming the resident — two same-dimension model spaces must never fuse in one cosine lane; swapping embedders is an explicit migration (re-attach every vector under the new tag). Order-sensitive flows (attach-then-retrieve) must send requests SERIALLY — the stdio server answers concurrent frames out of order (the initialize instructions' concurrency law). ONE embedding per capsule: a second put REPLACES the row (replace-on-write, no vector history) — recorded is STATE (always true; the embedding exists after the call), replaced:true names the overwrite. The embedding is stored as its exact little-endian f32 bytes (bit-exact round-trip) with the dimension recorded; an empty, non-finite (NaN/±inf), or zero-magnitude vector is rejected with a teaching -32602 (cosine is undefined for those), and an empty model_tag likewise. An unknown capsule_id is a resource-state error (-32002, data {kind:"unknown_capsule", id}) — the same family as memory_get. LIST: pass NOTHING to get every stored embedding's {capsule_id, dimension, model_tag} in append order (the vectors' bytes stay off the wire — this is the cheap index). How recall uses it: memory_retrieve lane auto preserves historical presence-based selection (term without query_embedding, fused with it); explicit term ignores stored vectors, explicit vector runs vector-only RRF, and explicit fused runs both lanes; vector/fused require query_embedding, whose dimension must match what you stored here. Vectors NEVER bypass the fences: quarantine, falsification, archive, supersession, freshness, and an optional fact-time window exclude from the vector lane IDENTICALLY to the term lane; under a time_window, a capsule without a declaration is undated in either lane (the fence-dominance law is lane-agnostic). Everything here is ADVISORY_NOT_AUTHORITY: an embedding is recall fuel, never authority, and dropping the whole vector table loses no canonical byte (Capsule v1 is frozen; vectors are a pure sidecar). Audited on put.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoAlias for `capsule_id` (pass one or the other, not both with different values).
embeddingNoPUT payload: the caller-computed embedding (`f32` vector). nmemory computes NO embedding — this is caller-fed. Mandatory on a put.
model_tagNoPUT provenance (MANDATORY on a put): the caller-declared model that produced `embedding` — the u6a provenance law. Opaque to the store.
capsule_idNoPUT target: the capsule the embedding attaches to (`cap-<n>`). `id` is an accepted alias — pass exactly one. Omit ALL fields to LIST the stored embeddings.
Behavior5/5

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

With no annotations, the description fully bears behavioral disclosure. It details that nmemory computes no embedding, stores one per capsule with replace-on-write, rejects invalid vectors, uses bit-exact storage, and describes error codes. It also explains how vectors interact with retrieval and fences, and that embeddings are advisory, not authority.

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 long but efficiently organized: starts with core purpose, then details put/list, then retrieval interaction, then fences and advisory nature. Every sentence adds value for a complex tool, though some sections could be slightly more compact. Still, it is very well-structured.

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 no output schema and high complexity, the description covers all necessary aspects: input semantics, validation, error conditions, behavior under concurrent access, and integration with memory_retrieve. It explains both put and list modes thoroughly, making the tool fully understandable.

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?

Schema coverage is 100%, but the description adds significant meaning beyond the schema. It explains the alias relationship between id and capsule_id, the mandatory nature of model_tag on put, the meaning of omitting all fields for list, and validates constraints. This enriches the schema substantially.

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 states the tool attaches or lists a caller-fed embedding, clearly distinguishing it from other memory operations by emphasizing that nmemory computes no embedding and that this is a pure sidecar. It explicitly contrasts with memory_retrieve usage.

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?

The description provides explicit guidance on when to use this tool (to attach embeddings for vector retrieval), when not to (if no embedding needed), and alternatives (e.g., explicit term ignores stored vectors). It explains the one-embedder-per-store rule, serial requirement for order-sensitive flows, and how retrieval uses stored vectors.

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