Skip to main content
Glama
Sign In
closure_drift

closure_drift

by luizfnsilva
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Check before tagging

would_tag
Read-onlyIdempotent

Checks whether the version declared at HEAD would reuse an existing git tag label before a release tag is created. Exit 1 means do not tag; bump the version first.

Instructions

Use BEFORE creating a release tag: would the version that HEAD declares reuse a label that already names other code in the tags? Exit 1 means do not tag; bump the version first. 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

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. Changed2 schema fields changedv1.2.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.3/5.0
Behavior5/5

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

Beyond annotations, it explains all three exit codes, stresses that exit 2 is not a pass, and gives examples of why exit 2 occurs. It also confirms read-only local git reads with no network, aligning with and enriching the annotation profile.

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 instruction and then efficiently covers exit-code semantics and read-only behavior. Every sentence contributes operational meaning without unnecessary repetition.

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?

Given the single parameter, existing output schema, and rich annotations, the description supplies the missing behavioral context an agent needs: when to call it, how to interpret exits, and why exit 2 is not success. No critical pre-call information appears to be 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?

There is only one parameter and schema description coverage is 100%, so the schema already explains that `repo` is a local git repository with tags fetched. The description reinforces the local-repository context but adds no additional syntax or constraints beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific pre-tag check: whether the version declared by HEAD would reuse a label already present in tags. It is clear about the resource and operation, but it does not explicitly distinguish itself from siblings like check_versions or compare.

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 gives a clear usage context: "Use BEFORE creating a release tag" and explains that exit 1 means do not tag and bump the version first. It does not state when to choose a sibling tool instead, so it stops short of full alternative routing guidance.

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