Skip to main content
Glama

semver_compare

Idempotent

Compare two TypeScript library versions to detect breaking API changes and recommend the SemVer bump, using paths, git refs, or npm specs.

Instructions

Compare two versions of a TypeScript library and detect breaking API changes. Use it to decide or check a SemVer bump; use semver_snapshot to list what one version exports without comparing it. Either side can be a filesystem path, a git ref, or an npm spec, so a working tree can be compared against the published release without checking anything out.

npm specs and git refs need network access and are unpacked into temp directories that are removed afterwards; nothing in a local path is written unless "installDeps" is set.

Returns the recommended SemVer bump (major/minor/patch) and a list of changes. Each change carries a confidence: "proven" (a structurally confident break) or "heuristic" (a conservative major the tool could not prove safe), and summary.majorProven / majorReview split the major count accordingly. The "gate" field gives what each CLI gate would exit with: "strict" fails only on a proven break, "strictReview" on any major. A "strict" pass does not mean nothing broke, since a break the tool could not prove stays review-only, so report both. Pass "declared" to grade the release against the bump it writes down instead of recommending one; a major it already declares then passes both gates.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "old": "<old>"
    },
    "name": "semver_compare"
  }
}

Input Schema

NameRequiredDescriptionDefault
newNoNew version: a filesystem path, a git ref, or an npm spec. Defaults to current directory..
oldYesOld version: a filesystem path, a git ref (tag, branch, commit SHA), or an npm spec. A "name@version" that is not an existing path is read as npm (e.g. "lodash@4.17.21", "lodash@latest"); prefix with "npm:" to say so outright.
entryNoEntry file relative to project root (e.g. "src/index.ts"). Pass an array or a comma-separated string for a package with several entry points. Auto-detected from package.json if omitted.
newAsNoForce "new" to be treated as a filesystem path, a git ref, or an npm spec. "ref" is an accepted spelling of "git".
oldAsNoForce "old" to be treated as a filesystem path, a git ref, or an npm spec. "ref" is an accepted spelling of "git". Only needed when auto-detection would read the input as the wrong kind, which is what a monorepo tag shaped like "pkg@1.2.3" needs.
declaredNoThe bump this release declares, or "auto" to read it from .changeset/*.md and then the two package.json versions. Adds a "declaration" verdict to the report: "mismatch" when a proven break outranks the declaration, "review" when the changes argue for more than was declared, "ok" otherwise. Errors when "auto" finds nothing to read, rather than reporting a pass.
maxChangesNoHow many changes to include (default 50). They are ordered proven breaks first, then additions, then review-only ones, so the cap drops the least actionable end. "summary" always counts every change, and an "omitted" field reports what was left out and the number to pass to get all of it.
installDepsNoInstall dependencies before analysis. In a local path with no node_modules this runs "npm install --ignore-scripts" in that directory, and adds @types/node there if it is missing. Only a local path needs it: a git ref is always installed in its temp copy.

Output Schema

NameRequiredDescriptionDefault
gateYes
changesYes
omittedNo
summaryYes
declarationNo
recommendedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.17.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "changes": {
      +      "items": {
      +        "properties": {
      +          "confidence": {
      +            "enum": [
      +              "proven",
      +              "heuristic"
      +            ],
      +            "type": "string"
      +          },
      +          "kind": {
      +            "type": "string"
      +          },
      +          "message": {
      +            "type": "string"
      +          },
      +          "newValue": {
      +            "type": "string"
      +          },
      +          "oldValue": {
      +            "type": "string"
      +          },
      +          "severity": {
      +            "enum": [
      +              "major",
      +              "minor",
      +              "patch"
      +            ],
      +            "type": "string"
      +          },
      +          "symbolPath": {
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "kind",
      +          "severity",
      +          "symbolPath",
      +          "message"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "declaration": {
      +      "properties": {
      +        "declared": {
      +          "enum": [
      +            "major",
      +            "minor",
      +            "patch",
      +            "none"
      +          ],
      +          "type": "string"
      +        },
      +        "required": {
      +          "enum": [
      +            "major",
      +            "minor",
      +            "patch"
      +          ],
      +          "type": "string"
      +        },
      +        "source": {
      +          "type": "string"
      +        },
      +        "suggested": {
      +          "enum": [
      +            "major",
      +            "minor",
      +            "patch"
      +          ],
      +          "type": "string"
      +        },
      +        "verdict": {
      +          "enum": [
      +            "ok",
      +            "review",
      +            "mismatch"
      +          ],
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "declared",
      +        "source",
      +        "required",
      +        "suggested",
      +        "verdict"
      +      ],
      +      "type": "object"
      +    },
      +    "gate": {
      +      "properties": {
      +        "strict": {
      +          "enum": [
      +            "pass",
      +            "fail"
      +          ],
      +          "type": "string"
      +        },
      +        "strictReview": {
      +          "enum": [
      +            "pass",
      +            "fail"
      +          ],
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "strict",
      +        "strictReview"
      +      ],
      +      "type": "object"
      +    },
      +    "omitted": {
      +      "properties": {
      +        "count": {
      +          "type": "integer"
      +        },
      +        "note": {
      +          "type": "string"
      +        },
      +        "total": {
      +          "type": "integer"
      +        }
      +      },
      +      "required": [
      +        "count",
      +        "total",
      +        "note"
      +      ],
      +      "type": "object"
      +    },
      +    "recommended": {
      +      "enum": [
      +        "major",
      +        "minor",
      +        "patch"
      +      ],
      +      "type": "string"
      +    },
      +    "summary": {
      +      "properties": {
      +        "major": {
      +          "type": "integer"
      +        },
      +        "majorProven": {
      +          "type": "integer"
      +        },
      +        "majorReview": {
      +          "type": "integer"
      +        },
      +        "minor": {
      +          "type": "integer"
      +        },
      +        "patch": {
      +          "type": "integer"
      +        }
      +      },
      +      "required": [
      +        "major",
      +        "minor",
      +        "patch",
      +        "majorProven",
      +        "majorReview"
      +      ],
      +      "type": "object"
      +    }
      +  },
      +  "required": [
      +    "recommended",
      +    "changes",
      +    "summary",
      +    "gate"
      +  ],
      +  "type": "object"
      +}
  2. Changed1 schema field changedv0.15.2
    • changedInput schema / properties / installDeps / description
      Previous value: -"Install dependencies before analysis (needed for local paths without node_modules)"New value: +"Install dependencies before analysis. In a local path with no node_modules this runs \"npm install --ignore-scripts\" in that directory, and adds @types/node there if it is missing. Only a local path needs it: a git ref is always installed in its temp copy."
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only give readOnlyHint=false and openWorldHint=true; the description adds concrete behavior beyond that: npm specs and git refs need network access and are unpacked into temp directories that are removed afterwards, and nothing in a local path is written unless installDeps is set. It also explains the gate semantics and warns that a 'strict' pass does not mean nothing broke, which is non-obvious and highly actionable.

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 purpose and sibling routing, then behavior, then return shape, then the declared mode — a sensible order. Some content (the return-value paragraph) overlaps the existing output schema, and the density is high, but no sentence is purely 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?

For an 8-parameter, open-world, mutating-under-flag tool with an output schema, the description covers side effects, network requirements, temp-directory cleanup, the gate semantics, and the review-only limitation. An agent has enough to call it correctly and interpret the result responsibly.

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, but the description adds real meaning: oldAs is justified by the monorepo-tag case, maxChanges ordering is explained (proven breaks, then additions, then review-only), and 'declared' is described in terms of the declaration verdict it produces. It stops short of full syntax detail, but goes beyond restating 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?

Opens with a specific verb and resource ('Compare two versions of a TypeScript library and detect breaking API changes') and immediately names the sibling it is not ('use semver_snapshot to list what one version exports without comparing it'). An agent can route between the two without opening either schema.

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?

States the decision it supports ('decide or check a SemVer bump'), names the alternative tool and its distinct purpose, and adds a further mode distinction ('Pass "declared" to grade the release against the bump it writes down instead of recommending one'). When-to-use and when-not-to-use are both explicit.

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