Skip to main content
Glama
Sign In
closure_drift

closure_drift

by luizfnsilva
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Measure all version labels

check_versions
Read-onlyIdempotent

Audit all git tags to verify each version label names exactly one code state. Returns exit 0, 1, or 2 plus a JSON report; exit 2 means undecided, not a pass.

Instructions

Use to audit the whole tag history: does each version label name exactly one code state? For a single release about to be tagged, use would_tag. With one release only, the answer is not decided (exit 2). Returns exit 0, 1 or 2 and the JSON report. Exit 2 is not a pass: nothing was decided, and output says why (no label found, a file not read, a tag not compared). Read-only: it runs git reads only, on the local repository, with no network.

Input Schema

NameRequiredDescriptionDefault
repoYespath to a local git repository with its tags fetched
strictNoanswer clean only if every tag scanned was compared (default false)
published_fileNoa local file with the versions actually released, one per line; tags not on it are not counted as publications

Output Schema

NameRequiredDescriptionDefault
exitYes0 clean, 1 drift, 2 not decided (the reason is in output)
outputYesthe JSON report (docs/REPORT.md), or the refusal as text
meaningYesthe exit code in words

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.2.0
    • changedInput schema / properties / published_file / description
      Previous value: -"optional file with the versions actually released, one per line"New value: +"a local file with the versions actually released, one per line; tags not on it are not counted as publications"
    • changedInput schema / properties / repo / description
      Previous value: -"path to a local git repository"New value: +"path to a local git repository with its tags fetched"
    • changedInput schema / properties / strict / description
      Previous value: -"clean only if every tag scanned was compared"New value: +"answer clean only if every tag scanned was compared (default false)"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "exit": {
+      "description": "0 clean, 1 drift, 2 not decided (the reason is in output)",
+      "enum": [
+        0,
+        1,
+        2
+      ],
+      "type": "integer"
+    },
+    "meaning": {
+      "description": "the exit code in words",
+      "type": "string"
+    },
+    "output": {
+      "description": "the JSON report (docs/REPORT.md), or the refusal as text"
+    }
+  },
+  "required": [
+    "exit",
+    "meaning",
+    "output"
+  ],
+  "type": "object"
+}
  2. First observedv1.1.1

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, local, non-destructive behavior, but the description adds valuable context beyond them: it runs git reads only, uses no network, returns exit 0/1/2 plus a JSON report, and explains that exit 2 means nothing was decided and why.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the primary use case and the sibling alternative, then concisely covers exit semantics and read-only behavior. Every sentence carries operational value.

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 complex audit tool with an output schema, rich annotations, and full parameter documentation, the description supplies the remaining needed context: when to use it, when not to, exit-code meaning, and local-git/no-network behavior.

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?

Schema description coverage is 100%, so the three parameters are already documented in the schema. The description does not add parameter-specific meaning for strict or published_file, so the baseline score of 3 is appropriate.

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 audit action over the whole tag history and frames the core question precisely: whether each version label names exactly one code state. It also distinguishes the tool from sibling would_tag for single-release checks.

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?

Explicitly says to use this for whole tag-history audits and routes single-release tagging checks to would_tag. It also calls out the edge case of one release only being undecided via exit 2.

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