Skip to main content
Glama
Sign In
closure_drift

closure_drift

by luizfnsilva
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Explain a label in drift

explain_label
Read-onlyIdempotent

Lists the file paths that differ across tags sharing one version label after drift is detected, so you can see what changed between the first and later tags.

Instructions

Use after check_versions reports drift: lists, for one label, the paths that differ between the first tag that used it and each other tag that did. For two references you choose, use compare. 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
labelYesa version label reported in drift, as written in the report (e.g. 1.0.0)

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. Changed3 schema fields changedv1.2.0
    • addedInput schema / properties / label / description
      Added value: +"a version label reported in drift, as written in the report (e.g. 1.0.0)"
    • 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"
    • 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.6/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, non-destructive, idempotent, closed-world), yet the description adds genuinely new behavior: exit codes 0/1/2, that exit 2 means nothing was decided, and reasons it can occur. It also restates the local-git-reads-only constraint, rounding out operational context beyond structured fields.

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 the trigger condition and core action; the exit-code sentence is dense but earns its place for a tool whose status codes are semantically meaningful. Slightly heavy, but no filler.

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?

Output schema exists so return values needn't be explained, and the description still covers the exit-code contract and failure modes. For a 2-param read-only tool, nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so both params are already documented (repo path with tags fetched, label as written in drift). The description reinforces label semantics via 'first tag that used it' but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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 verb and resource (list paths that differ for one label between tags) and explicitly differentiates from siblings: 'Use after check_versions reports drift' and 'For two references you choose, use compare.' An agent can place this tool precisely among its siblings without opening schemas.

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?

Explicit ordering guidance (use after check_versions reports drift) and a named alternative with the condition that selects it (compare for two arbitrary references). When-to-use is unambiguous.

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