Skip to main content
Glama
0Mattias
by 0Mattias

memory_verify

Verify a memory's stored claims against the live filesystem and git state, confirming paths, versions, and configurations remain accurate.

Instructions

Bump last_verified_at to now after spot-checking that a memory's claims still match reality (file paths exist, version still matches, configuration still what it says).

Orthogonal to content edits: this tool does NOT bump updated; memory_update does NOT bump last_verified_at. A typo fix bumps updated only; a verify call bumps last_verified_at only. Idempotent — calling twice slides the timestamp forward.

Parameters:

  • id: memory id.

  • note (optional, ≤500 chars): what was checked, for the event log.

  • verified_paths (optional list of strings): the ONLY attestation the drift legs read — checked against the memory's own worktree, and the anchor narrowing commit drift. Prefer it when the memory cites paths. Paths absent here are REFUSED.

  • verified_commits / verified_versions (optional lists): audit trail only; nothing on the read path resolves them.

  • verified_absent_paths (optional): attest paths INTENTIONALLY absent here (remote host, other platform, not-the-location) — reported under expected_absent, not missing. Never for real drift.

  • claims (optional): memory_write's claim syntax; checked NOW, false ⇒ refused. Stored claims re-check on every verify — a false one blocks the stamp; memory_update first. All five lists are REPLACE, not append — None preserves the prior attestation, [] clears it, a populated list supersedes it. Attest the full set each time.

After memory_update on a memory you later spot-check, verify again — memory_update clears last_verified_at because the prior verification was for prose that no longer exists.

Returns status="stale" when another agent verified first; the hint says to re-fetch and re-attest.

Also resolves an unresolved record_use(contradicted) flag in memory_health when the body still matches reality.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
noteNo
claimsNo
verified_pathsNo
verified_commitsNo
verified_versionsNo
verified_absent_pathsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses idempotency, the side effect on `last_verified_at` only (not `updated`), the staleness status when another agent verifies first, the refusal behavior for paths absent from `verified_paths`, and the side effect of resolving a `record_use(contradicted)` flag.

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?

The description is longer than typical, but it is densely informative and well-organized, moving from core purpose to parameter groups to side effects. Every sentence adds necessary operational detail. It is slightly verbose but earn every word given the tool's complexity.

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?

For a tool with 7 params, no annotations, and an output schema (not shown), the description covers the critical return status (`status='stale'`), the meaning of the `hint`, and the side-effect resolution of a health flag. It also spells out edge cases (empty-list semantics, absent-path attestation). It is complete enough for an agent to invoke safely and correctly.

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?

Schema description coverage is 0%, but the description adds rich semantics for all seven parameters. It explains the exact role of each list (e.g., `verified_paths` is 'the ONLY attestation the drift legs read'), the REPLACE semantics of all five lists, and the behavioral consequences of `claims` (checked now, false ⇒ refused). This entirely compensates for the lack of schema descriptions.

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 verb ('Bump `last_verified_at` to now after spot-checking...') and clearly identifies the resource (a memory). It explicitly contrasts with memory_update by stating what this tool does NOT do (bump `updated`), distinguishing it from the closest sibling.

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?

The description provides explicit when-to-use guidance: 'Prefer it when the memory cites paths' for verified_paths, and states when verification is needed again ('After memory_update on a memory you later spot-check, verify again'). It also explicitly names the alternative (memory_update) and explains the division of labor.

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/0Mattias/bettermemory'

If you have feedback or need assistance with the MCP directory API, please join our Discord server