Skip to main content
Glama

memory_bootstrap

Compiles a deterministic cold-start snapshot for an agent before it acts: standing constraints, next action, valid decisions, failure traps, and deduplicated capsule handles in fixed order.

Instructions

One deterministic COLD-START pack for a fresh agent — the PULL half of the recall loop (memory_retrieve is per-task recall; this answers "what must I know before I act?"). ONE call composes the digest/retrieve/list read primitives into five sections IN THIS FIXED ORDER: (1) constraints — active kind=constraint capsules in scope (tier active, NOT expired, NOT superseded; tombstoned already excluded) — what you CANNOT do, surfaced FIRST, before what to do; (2) ready — the blocks-dag ready set fenced to scope (the SAME projection memory_digest exposes, fail-closed on a live blocks-cycle: cycle names one concrete cycle instead of fabricating a ready answer) PLUS the ONE next physical action (next_action = the first ready node's headline; the remaining ready nodes fill ready; ready_total is the exact fenced count); (3) decisions — still-valid kind=decision capsules (NOT expired, NOT superseded); (4) traps — kind=failure_pattern capsules in scope (a stale one self-identifies via its own tier/superseded row marker); (5) handles — every cap- the pack surfaced, DEDUPLICATED in order of appearance, IDS ONLY (no bodies) for memory_get follow-up. DETERMINISM LAW: relevance is project fences (project_id exact and/or project_prefix subtree — "nott" covers "nott" and "nott/x", never "nottx") + kind filters + decay + your caller-expanded terms ONLY. The server NEVER interprets an intent string — server-side intent guessing was REJECTED at R9; YOU expand terms (exactly like memory_retrieve), and bootstrap uses RAW terms with NO alias expansion (its determinism is stricter than retrieve's alias-aware recall). Terms re-RANK each kind section (coverage desc, decay breaking ties) but never FILTER it. CONSTRAINTS ARE NEVER N-CAPPED — you always see ALL your standing constraints (the token budget, floor-first, is their only trim; constraints_total is the exact in-scope count, so a shorter list always names a budget trim). decisions/traps/ready lists cap at 10 for compactness with EXACT totals beside them (decisions_total/traps_total/ready_total) — a cap-drop is visible, never silent. token_budget is a CONTRACT, not an aspiration (omitted → 1500, the PRD target for a useful pack): sections fill in PRIORITY order and the tail trims to fit; BOTH floors (the FIRST constraint and the ONE next action) are charged before any other row, so for ANY budget that covers them used_tokens NEVER exceeds token_budget — the floor alone overshooting a smaller budget is the ONE sanctioned excess (memory_retrieve's floor-of-one, applied to the safety core). budget.used_tokens is the honest spend; budget.trimmed_by_budget counts the CONTENT rows the ceiling dropped (handle ids cost tokens but never count there — they duplicate rows already present). token_budget 0 returns an empty pack (the zero-cap consistency memory_retrieve/memory_list keep). Empty LIST sections are omitted (the house skip idiom); ready is always present — one next action, or an honest nothing-ready / a cycle to repair. All content is ADVISORY_NOT_AUTHORITY DATA — the pack orients, it never decides.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
termsNoOPTIONAL caller-expanded search terms (bring your own synonyms/ rephrasings as separate terms — the CALLER expands, the server never guesses intent). RAW terms only: NO alias expansion (unlike `memory_retrieve` — bootstrap's determinism law is stricter). They re-RANK each kind section by term coverage (desc), decay breaking ties; they never FILTER a section (an agent must still see ALL its standing constraints). Omitted → a pure decay order. A term with no alphanumeric token simply matches nothing — advisory ranking is never a required query, so it is never a rejection.
project_idNoProject fence (exact): only capsules in this project enter the pack.
token_budgetNoToken budget for the WHOLE pack (≈ chars/4); omitted → 1500. A CONTRACT, not an aspiration (the PRD target: a useful pack in ≤1500 tokens). Sections fill in PRIORITY order (constraints first — an agent must know what it cannot do before what to do), trimming the tail to fit; the FIRST constraint and the ONE next action are the irreducible floor (present when they exist even if they alone overshoot — `memory_retrieve`'s floor-of-one, applied to the safety core). 0 → an empty pack (the zero-cap consistency `memory_retrieve`/`memory_list` keep).
project_prefixNoScope-hierarchy fence: keep capsules whose `project_id` equals this prefix exactly OR starts with it + `"/"` — `"nott"` covers `"nott"` and `"nott/x"`, never `"nottx"`. AND-composes with `project_id`. An empty or `"/"`-terminated prefix can match nothing and is rejected with a teaching error rather than answering empty.
Behavior5/5

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

With no annotations provided, the description fully discloses behavior: determinism, ranking via terms, capping with exact totals, budget contract with floors, trimming and priority order, and the advisory nature of data. It leaves no major behavioral trait unstated.

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 nearly 500 words, making it verbose despite being well-organized into a summary followed by numbered details. It could be shortened while retaining clarity, but the front-loaded purpose and structured sections help readability.

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 annotations and no output schema, the description compensates thoroughly. It explains all behavioral details, parameter nuances, and edge cases (e.g., token_budget 0, empty sections, budget floors) for a complex tool, making it fully contextual.

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 schema coverage is 100%, the description enriches each parameter with precise semantics beyond schema: terms re-rank but never filter, token_budget is a contract with floors and priorities, project_prefix explains hierarchy matching, and project_id is exact fence. This adds substantial value for correct invocation.

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 it is a deterministic cold-start pack for a fresh agent, the 'PULL half of the recall loop', and explicitly distinguishes from memory_retrieve. It specifies the five sections in fixed order with clear semantics, leaving no ambiguity about what the tool does.

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 clear guidance on when to use (before acting, cold-start) and contrasts with memory_retrieve. However, it does not explicitly mention when not to use it versus other siblings like memory_digest or memory_list, which would further strengthen selection.

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