Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
SEMVER_CHECKS_VERBOSENoSet 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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.7/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityNo data
ResponsivenessOutdated data