Skip to main content
Glama
Sign In
closure_drift

closure_drift

by luizfnsilva
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Compare two references

compare
Read-onlyIdempotent

Identify differences between any two named tags or commits: version labels, closures and changed paths, with exit codes and a JSON report for release decisions.

Instructions

Use to compare any two tags or commits you name: their version labels, closures and the paths that differ. Publication points play no part. Exit 1 when both declare one label and the code differs. 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
aYesthe first tag or commit (the reference side)
bYesthe second tag or commit; paths are listed as changed, only in a, only in b
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. Changed4 schema fields changedv1.2.0
    • addedInput schema / properties / a / description
      Added value: +"the first tag or commit (the reference side)"
    • addedInput schema / properties / b / description
      Added value: +"the second tag or commit; paths are listed as changed, only in a, only in b"
    • 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?

Beyond the annotations, it discloses the full outcome contract: exit 0/1/2 semantics, that exit 1 means both declare one label but code differs, and that exit 2 means nothing was decided with a stated reason. It also confirms the read-only, local-only, no-network execution profile, which is richer than readOnlyHint alone.

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 purpose, then the outcome contract in a compact sequence. The exit-code sentences are dense but each carries decision-relevant information; the sole visible duplication is the no-network clause already implied by openWorldHint=false.

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 3-required-param comparison tool with an output schema, this covers the gaps that matter: how to read exit codes, what exit 2 means operationally, and that execution is local and side-effect free. Nothing an agent needs to invoke and interpret the call is missing.

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?

Schema coverage is 100%, so the baseline is 3; the description adds that both operands are user-named tags or commits and clarifies the directional semantics of the comparison output ('only in a, only in b'). It does not add format or resolution rules (e.g. ambiguous tag vs branch names) beyond the schema.

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 (compare two tags or commits) and enumerates exactly what the comparison yields: version labels, closures, and differing paths. 'Publication points play no part' implicitly separates it from the release/publication-oriented siblings like would_tag.

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?

'Use to compare any two tags or commits you name' gives a clear trigger plus the exit-code contract that tells the agent how to interpret outcomes. It does not explicitly name the sibling alternatives (check_versions, explain_label) or state when not to use it, which keeps it short of a 5.

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