Skip to main content
Glama
MerakOsiris

MemoryGuard

by MerakOsiris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

memoryguard_context_bootstrap

Build bounded mandatory rules and relevant governed memory context at task start, preventing repeated lookups and establishing a focused working set for the task.

Instructions

Use when starting one new task to build bounded mandatory rules and relevant governed memory context. Do not use for exact record lookup or repeatedly within same task. Uses trusted binding and may mark one pending local CodeGraph receipt consumed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskYescurrent task or request; required
max_charsNomaximum characters for optional recalled content; mandatory rules use their separate budget
max_itemsNomaximum optional memories to include; mandatory rules use their separate budget
read_pathNoPhase5 canonical read path: auto uses canonical only when the group is canonically ready, otherwise the native compatibility read path; rule-intelligence prefers the rule-intelligence layer, deduplicating merged duplicates only after the active/audience/exclude matchauto
max_tokensNooptional total-token budget forwarded to the V2 ContextEngine
project_hintNooptional project/repository hint used only for relevance

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.7.12
    • addedInput schema / properties / max_chars / description
      Added value: +"maximum characters for optional recalled content; mandatory rules use their separate budget"
    • addedInput schema / properties / max_items / description
      Added value: +"maximum optional memories to include; mandatory rules use their separate budget"
  2. First observedv0.7.8

TDQS

A4.4/5.0
Behavior4/5

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

Annotations are all false and uninformative, so the description carries the behavioral burden. It adds a meaningful non-obvious side effect: 'may mark one pending local CodeGraph receipt consumed.' This exceeds annotation coverage and helps an agent anticipate state change, though 'Uses trusted binding' remains somewhat vague about what that entails.

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

Conciseness5/5

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

The description is two sentences, front-loaded with the primary use case, followed by exclusions and side effects. Every clause contributes something: when to use, when not to use, and behavioral caveats. There is no padding or repetition.

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

Completeness4/5

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

For a tool with six parameters and no output schema, the description covers the essential operational context: purpose, usage boundaries, and side effects. The schema covers parameters, so the remaining gap is minor—terms like 'trusted binding' and 'pending local CodeGraph receipt' are not explained, but the overall call guidance is sufficient.

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 description coverage is 100%, and the input schema already documents each parameter, including defaults, bounds, and enums. The description itself does not elaborate on individual parameters, so it adds no semantic value beyond the schema. Baseline 3 is appropriate.

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 use case and resource: 'starting one new task to build bounded mandatory rules and relevant governed memory context.' It also actively distinguishes itself from siblings by saying 'Do not use for exact record lookup or repeatedly within same task,' so an agent can tell it apart from recall and search tools without opening schemas.

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?

It gives explicit when-to-use ('Use when starting one new task') and when-not-to-use guidance ('Do not use for exact record lookup or repeatedly within same task'). While it does not name sibling tools, the positive and negative instructions are unambiguous enough to route an agent correctly.

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