Skip to main content
Glama
Sign In
DanceNitra

inspeximus

by DanceNitra
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

check_sources

Check stored agent-memory sources: report which still resolve and match fingerprints, which drifted, and which are gone.

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 whenever NOTHING was checked -- zero drifted over zero checked is not a clean store -- including a store whose records carry no source at all (every record NOT_BINDABLE). verdict names the state: CLEAN (something was checked and nothing moved), DRIFTED (a source changed, vanished, or had already moved at capture) or NOT_CHECKED; not_checked counts the records that could not be checked by reason, the coverage ratios are null rather than 0, and a problem 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

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.20.1

TDQS

A4.6/5.0
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: it warns the return is a report not a boolean, defines all six record states, explains that `ok` is false even when nothing was checked, that ratios are null rather than 0, that `not_checked` is broken out by reason, and that results are scoped to the bound tenant/project. It even discloses a real deployment measurement to set expectations around UNCHECKABLE volume.

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 core purpose is front-loaded in the first two sentences and the state vocabulary is organized and scannable. It runs long and circles the 'nothing was checked is not clean' point three times plus adds a deployment-statistics aside, but the length is largely justified by having no output schema to carry the return contract.

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?

With no output schema, the description must define the return surface, and it fully does: every state, the `verdict` values, `ok`, `not_checked`, null ratios, and the `problem` field. Zero parameters means no argument gaps, and tenant/project scoping is covered, so an agent has everything needed to call and interpret this.

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?

The tool takes zero parameters, so per the calibration there is nothing for the description to clarify at the argument level; baseline 4 applies. Schema coverage is 100% and no enum/format guidance is needed.

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 opening line states a specific verb and resource ('check_sources' -> has the SOURCE each memory came from changed), gives the expected output form ('Returns a report, not a boolean'), and explicitly separates itself from the temporal-decay family of tools in the same library. An agent can distinguish this from siblings like verify_writes or audit_the_audits without opening a schema.

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 clearly frames when this is the right question to ask ('age cannot tell a fact that has been true for five years from one that rotted in a week') and gives operational guidance ('READ UNCHECKABLE FIRST'). It stops short of naming specific alternative tools or stating when NOT to use it, so it is strong context rather than explicit routing.

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