Skip to main content
Glama
Goldentrii

AgentRecall

by Goldentrii
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Check Understanding

check

Validate understanding, verify alignment with human intent, and preflight high-risk actions against recorded corrections before publishing, deploying, deleting, or sending externally.

Instructions

[MID-SESSION — safe any time; for alignment, before risky decisions] Use when the user asks to validate understanding, verify alignment, or check if their interpretation matches the human's intent. Also call BEFORE a high-risk action — publish, deploy, delete, credential exposure, external send/message, or any other irreversible write — passing action_description (one sentence, what you're about to do). Returns matching corrections/rules/insights plus a verdict: blocked means an authoritative correction OVERRIDES the plan — read it before proceeding. To RECORD a durable human correction, pass human_correction as the STRUCTURED object {rule, why, applies_when} — a plain string is only STAGED for later review, never activated.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalNoThe goal or decision question you're checking alignment on. Required for alignment checks; optional when recording a pure decision trail (prior/posterior/evidence).
deltaNoThe gap between your understanding and reality (or 'none').
priorNoInitial probability estimate (0-1). Start of Bayesian decision trail.
outcomeNoFinal decision result: 'confirmed', 'rejected', 'partial', or free text. Triggers decision trail persistence.
projectNoauto
evidenceNoEvidence collected since prior. Each entry shifts probability.
posteriorNoUpdated probability after considering evidence (0-1).
confidenceNoHow confident you are. Defaults to medium.medium
assumptionsNoKey assumptions you're making.
decision_idNoLink multiple check calls to the same decision. Auto-generated if not provided.
understandingNoAlias for goal — use when saying 'check my understanding: X'. Provide either goal or understanding.
human_correctionNoAfter human responds: what they actually wanted. Pass the OBJECT form {rule, why, applies_when} to activate a durable correction; a plain string is only staged for review.
action_descriptionNoWhat you're about to DO, one sentence — pass this before publish/deploy/delete/credential/external-send/irreversible-write actions. Returns matching corrections/rules/insights on the result's `action_check` field, with `verdict: "blocked"` when an authoritative correction overrides the plan.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv3.4.50
    • addedInput schema / properties / human_correction / anyOf
      Added value: +[
+  {
+    "description": "LEGACY string form — STAGED to the pending-review store, NOT activated. Prefer the object form.",
+    "type": "string"
+  },
+  {
+    "description": "STRUCTURED correction — the ONLY form that reaches the active corrections ledger. Incomplete input is rejected with an agent_instruction explaining the fix.",
+    "properties": {
+      "applies_when": {
+        "description": "1-5 REAL context keywords (topics/domains, e.g. [\"git\",\"deploy\"]) — sentence fragments are rejected.",
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "pending_id": {
+        "description": "Id of a staged pending correction (from session_start's pending_corrections or a prior check result) — resolves it: promoted with a valid {rule,why,applies_when}, or discarded with resolution:'reject'.",
+        "type": "string"
+      },
+      "resolution": {
+        "description": "With pending_id: 'promote' (default; requires valid rule/why/applies_when) or 'reject' (discards the staged item; `why` doubles as the reject reason).",
+        "enum": [
+          "promote",
+          "reject"
+        ],
+        "type": "string"
+      },
+      "rule": {
+        "description": "ONE imperative, self-contained sentence stating the durable behavior (e.g. \"Never publish without explicit owner approval\"). Questions/status statements are rejected.",
+        "type": "string"
+      },
+      "why": {
+        "description": "Concrete evidence behind the rule — what happened or what the human said. Required for activation.",
+        "type": "string"
+      }
+    },
+    "type": "object"
+  }
+]
    • changedInput schema / properties / human_correction / description
      Previous value: -"After human responds: what they actually wanted (or 'confirmed')."New value: +"After human responds: what they actually wanted. Pass the OBJECT form {rule, why, applies_when} to activate a durable correction; a plain string is only staged for review."
    • removedInput schema / properties / human_correction / type
      Removed value: -"string"
  2. Addedv3.4.40
  3. Removedv3.4.38
  4. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden and does so well: it explains that `verdict: blocked` means an authoritative correction overrides the plan, and that a plain-string human_correction is only staged while the object form activates a durable rule. These are non-obvious operational consequences that an agent cannot infer from the schema alone. It omits any statement of side effects of the decision-trail mode or error behavior.

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 a bracketed timing tag ('MID-SESSION — safe any time') before the prose, so the agent gets the when first. It is dense and longer than most, and the action_description guidance partly repeats the schema text, but nearly every sentence carries actionable routing or semantics.

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

Completeness3/5

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

For a 13-parameter tool with no annotations and no output schema, the description covers the alignment and pre-action modes thoroughly and describes the return payload (corrections/rules/insights plus verdict). However, the Bayesian decision-trail feature (prior/posterior/evidence/decision_id/confidence/assumptions/outcome) is essentially undocumented in the description, leaving a large chunk of the tool's surface explained only by the schema.

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 92%, so the schema already documents most parameters (baseline 3), but the description adds real value beyond it: it specifies that action_description should be one sentence of what you're about to DO, and draws the critical distinction between the string form (staged) and the structured {rule, why, applies_when} form (activated). That meaning is not fully conveyed by the schema's own descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('check') against a concrete resource (alignment/understanding with human intent) and enumerates the situations that trigger it. It clearly distinguishes its role from the sibling memory tools by framing itself as a validation gate. The only blur is that it also silently carries correction-recording and decision-trail modes, which muddies the single-purpose framing.

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?

It gives explicit trigger conditions: user asks to validate/verify understanding, and pre-action checks before publish/deploy/delete/credential/external-send. It even points at session_start's pending_corrections for resolving staged items. It stops short of stating when NOT to use this versus remember/recall, so it is clear-but-not-exhaustive.

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