Skip to main content
Glama
vbcherepanov

total-agent-memory

by vbcherepanov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

self_rules_context

Read-onlyIdempotent

Get active behavioral rules for current session. Call at SESSION START to load rules. Returns rules filtered by project and scope.

Instructions

Get active behavioral rules for current session. Call at SESSION START to load rules. Returns rules filtered by project and scope. v8.0: pass phase to lazy-load rules relevant to current task phase — core rules (no phase tag) + rules tagged phase:. Cuts prompt tokens ~70%. After task completion, rate rules: self_rules(action='rate', id=X, success=true/false).

Input Schema

NameRequiredDescriptionDefault
phaseNoOptional: lazy-load only rules relevant to this phase (core + phase-specific). Omit to get all rules.
queryNoOptional task text: rank rules by relevance and return a surface_id per rule for self_rules(action='followed').
projectNogeneral
categoriesNoError categories relevant to current task
session_idNoOptional session for the surfaces (default: current).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv14.9.0
    • addedInput schema / properties / query
      Added value: +{
+  "description": "Optional task text: rank rules by relevance and return a surface_id per rule for self_rules(action='followed').",
+  "type": "string"
+}
    • addedInput schema / properties / session_id
      Added value: +{
+  "description": "Optional session for the surfaces (default: current).",
+  "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 this a readOnly, idempotent, non-destructive call, so the safety bar is low. The description still adds real behavioral value: results are filtered by project and scope, phase-tagged lazy loading 'cuts prompt tokens ~70%', and the rate-after-completion loop. No return format detail, but no output schema demands one.

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 action, then timing, then the version-specific phase behavior, then the cross-tool follow-up. Dense but each sentence carries distinct information; the 'v8.0' framing is slightly noise but the payoff sentence justifies it.

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?

Five optional, zero required parameters with no output schema, and the description covers the trigger moment, filtering behavior, phase semantics, and the follow-up rating step. Adequate for an agent to invoke correctly, though it never says what an empty rule set or an unknown phase returns.

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 80%, so most parameters explain themselves (the phase and query descriptions in the schema are already rich). The description still adds rationale beyond the schema: phase yields 'core rules (no phase tag) + rules tagged phase:<X>' and the ~70% token reduction that motivates it.

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 and resource ('Get active behavioral rules for current session') and immediately scopes it (filtered by project and scope). It also names the sibling it pairs with ('self_rules(action=...)'), so an agent can tell self_rules_context apart from self_rules and rule_set_phase.

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?

Explicit timing guidance: 'Call at SESSION START' and 'pass phase to lazy-load rules relevant to current task phase'. It also defines a follow-up workflow (rate rules after task completion) via a named sibling. It stops short of stating when NOT to use it or contrasting with rule_set_phase, but the context is otherwise unambiguous.

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