Skip to main content
Glama
vbcherepanov

total-agent-memory

self_rules

Manage behavioral rules (SOUL). Rules are promoted insights that shape agent behavior. Actions: list, fire (record relevance), rate (success=true/false), suspend, activate, retire, add_manual, followed (surface_id from…

Instructions

Manage behavioral rules (SOUL). Rules are promoted insights that shape agent behavior. Actions: list, fire (record relevance), rate (success=true/false), suspend, activate, retire, add_manual, followed (surface_id from self_rules_context(query=...): was the rule followed?), report (follow-rate effectiveness with Wilson CIs, measurement only). success_rate = success / (success + fail). Auto-suspend: 5+ ratings and the 95% upper bound of success_rate < 0.4.

Input Schema

NameRequiredDescriptionDefault
idNoRule ID (for fire/rate/suspend/activate/retire)
noteNoFor followed: evidence note
tagsNo
min_nNoFor report: judged surfaces needed before a verdict
scopeNoglobal | project:<name> | category:<name>global
actionYes
contentNoRule text (for add_manual)
projectNogeneral
successNoFor rate: was rule helpful?
categoryNoCategory (for add_manual)
followedNoFor followed: true followed, false ignored, null clears
priorityNo1-10
applicableNoFor followed: false marks the rule not applicable
surface_idNoFor followed: surface_id returned by self_rules_context

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv14.9.0
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "list",
      -  "fire",
      -  "rate",
      -  "suspend",
      -  "activate",
      -  "retire",
      -  "add_manual"
      -]New value: +[
      +  "list",
      +  "fire",
      +  "rate",
      +  "suspend",
      +  "activate",
      +  "retire",
      +  "add_manual",
      +  "followed",
      +  "report"
      +]
    • addedInput schema / properties / applicable
      Added value: +{
      +  "default": true,
      +  "description": "For followed: false marks the rule not applicable",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / followed
      Added value: +{
      +  "description": "For followed: true followed, false ignored, null clears",
      +  "type": [
      +    "boolean",
      +    "null"
      +  ]
      +}
    • addedInput schema / properties / min_n
      Added value: +{
      +  "default": 5,
      +  "description": "For report: judged surfaces needed before a verdict",
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / note
      Added value: +{
      +  "default": "",
      +  "description": "For followed: evidence note",
      +  "type": "string"
      +}
    • addedInput schema / properties / surface_id
      Added value: +{
      +  "description": "For followed: surface_id returned by self_rules_context",
      +  "type": "string"
      +}
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the write-style profile is known. The description adds genuine behavior not in annotations: the success_rate formula, the auto-suspend rule (5+ ratings and 95% upper bound of success_rate < 0.4), and the fact that 'report' is measurement-only. What it omits is whether suspend/retire are reversible or what the responses look like, so not a full 5.

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?

Front-loaded with the core purpose, then a terse action-by-action clause; every sentence carries information and there is no filler. It is dense to the point of being a long run-on, which costs a point on readability but not on substance.

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?

With 14 parameters, no output schema, and a multi-action surface, the description covers the dispatch semantics, the two formulas, and the sibling dependency on self_rules_context. It leaves response shapes and reversibility of suspend/activate/retire unstated, which is a minor gap given the annotation coverage.

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 79% and already documents most params. The description still adds action-scoped meaning the schema lacks: which id is for fire/rate/suspend/activate/retire, that success_rate = success/(success+fail), and that report's min_n controls the judged-surface threshold for a verdict. A few params (tags, priority, project) remain unexplained in prose.

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?

States a specific verb+resource ('Manage behavioral rules (SOUL)') and then enumerates all nine actions, so an agent immediately knows this is the multi-action dispatcher for the rules subsystem. It also distinguishes itself from the sibling self_rules_context by pointing to it explicitly for surface_id lookup.

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 action list effectively routes usage ('fire (record relevance)', 'followed ... was the rule followed?', 'report ... measurement only'), and it names the sibling self_rules_context as the source for surface_id. It does not state when NOT to use this tool versus memory-side siblings, so it stops short of a 5.

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