Skip to main content
Glama

check_sources

Checks whether the sources backing each memory have changed or vanished, returning a per-record report of statuses like fresh, drifted, or orphaned.

Instructions

CAUSAL staleness: has the SOURCE each memory came from CHANGED, or gone? Returns a report, not a boolean.

Decay elsewhere in this library is temporal — a half-life on age — and age cannot tell a fact that has been true for five years from one that rotted in a week. This asks the question that can: did the thing this memory is about actually change? Per record: FRESH (source resolves, still hashes the same), DRIFTED (resolves, content changed — re-read it, don't serve it blind), ORPHANED (an addressable source that is gone), UNRESOLVED_HERE (a relative or non-file locator the default resolver could not address from this working directory — read it with resolution_base, it is not evidence of absence), UNCHECKABLE (a source is named but carries no fingerprint, or names the WRITER rather than a document), NOT_BINDABLE (no source at all, e.g. a decision: nothing to fingerprint in any window, so it is left out of the denominator rather than counted as a gap).

READ UNCHECKABLE FIRST. Fingerprints are only taken when remember(source={"doc": <path>}) points at a file that existed at write time, so on most stores this is the large number and the honest denominator. ok is false when records name sources and NONE of them could be checked -- zero drifted over zero checked is not a clean store -- and a problem says so. A store whose records carry no source at all (every record NOT_BINDABLE) had nothing to check: ok is true there, checked is 0, the coverage ratios are null rather than 0, and a problem still says that nothing was verified. Measured on our own deployment before shipping this: 210,544 records, 98.3% carrying a source, 0.01% carrying one that resolves to anything you could fetch again.

Scoped to the bound tenant/project when there is one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.20.1

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden. It details all possible output statuses (FRESH, DRIFTED, ORPHANED, UNRESOLVED_HERE, UNCHECKABLE, NOT_BINDABLE) and explains the meaning of each, including important caveats like 'UNRESOLVED_HERE is not evidence of absence'. It also explains the semantics of `ok` and coverage ratios, including edge cases where no sources exist, and mentions scoping to tenant/project. This is exemplary behavioral disclosure.

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 quite long (roughly 350 words) but is well-structured: it opens with a clear purpose sentence, then explains each status in a dedicated paragraph, and ends with operational notes and deployment statistics. Every part contributes to understanding, though the deployment statistics paragraph ('Measured on our own deployment...') is arguably optional for invoking the tool. The layout is logical and front-loaded, but the length prevents a perfect score.

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?

The tool has no parameters and no output schema, so the description must explain the output, which it does thoroughly. However, the reference to 'resolution_base' is inconsistent with the provided schema (which has zero properties), creating ambiguity about whether the tool accepts arguments. Additionally, it does not explicitly state that the tool takes no arguments or clarify how `resolution_base` could be supplied. This detracts from completeness, making the score lower than it otherwise would be.

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?

The input schema has zero parameters, so the baseline is 4. However, the description mentions 'read it with `resolution_base`' as if there were a parameter named `resolution_base`, which does not exist in the schema. This is a misleading reference that could cause an agent to believe a parameter is required. Since the description fails to accurately reflect the schema and introduces a non-existent parameter, the score is lowered to 3.

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 first sentence states a specific verb ('check_sources'), resource (the SOURCE each memory came from), and the core question ('has the SOURCE...CHANGED, or gone?'). It also clearly distinguishes the tool from temporal decay tools ('Decay elsewhere in this library is temporal') and specifies that it returns a report, not a boolean. This gives an agent a precise understanding of what the tool does and how it differs from siblings.

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 description explicitly contrasts this tool with temporal decay ('age cannot tell a fact...'), thereby telling the agent when to use it (when causal staleness matters) and implies that temporal decay tools are alternatives. It does not name a specific sibling tool, but the distinction is clear. However, it does not provide explicit exclusions such as 'don't use if you only need a boolean' or name a specific replacement, so a 4 is appropriate.

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