semver-checks
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SEMVER_CHECKS_VERBOSE | No | Set SEMVER_CHECKS_VERBOSE=1 to enable full diagnostics when the analyzed project has TypeScript errors (semver-checks otherwise prints a warning to stderr listing up to 5 errors and continues). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| semver_compareA | 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. |
| semver_snapshotA | Extract the public API surface of a TypeScript project as JSON, without comparing it to anything. Use it to see what a package exports; use semver_compare to decide a bump. The source can be a filesystem path, a git ref, or an npm spec, the same three forms semver_compare takes, with the same network and temp-directory behaviour. Returns {"entrypoints": {: {: }}}, with each symbol's full type shape in place of its kind when "detail" is set. Symbols stop at the "maxBytes" budget, and an "omitted" field then gives the number left out and the total. A source whose surface comes back empty is reported as an analysis_failed error, not as an empty result; pass "entry" to point at the declaration file. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
semver_snapshot inspects one version's API surface while semver_compare diffs two versions; the two purposes never overlap. Each description explicitly states when to use the other tool, removing any residual ambiguity.
Both names follow a strict `semver_<object>` pattern with a shared prefix and parallel noun/verb forms (snapshot vs compare). There is no mixing of conventions or vague verbs.
Two tools is on the lean side, but the domain (semver bump analysis for TypeScript packages) is narrow enough that snapshot + compare fully covers it. Nothing feels padded or missing at the surface level.
The lifecycle is covered: inspect a single surface, compare two, and evaluate against a declared bump, across path/git/npm sources with gate semantics. Minor gaps exist around remediation or change-filtering, but core workflows have no dead ends.