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. 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.4/5.0

Scored across 2 tools

Disambiguation5/5

semver_compare and semver_snapshot have clearly distinct purposes: one diffs two versions to recommend or grade a SemVer bump, while the other only extracts an API surface. The descriptions explicitly direct agents to use snapshot for inspection and compare for bump decisions.

Naming Consistency5/5

Both tools follow a consistent semver_<action> snake_case pattern. The names are predictable and directly reflect their operations.

Tool Count4/5

Two tools is slightly thin against the typical 3-15 range, but this server has a narrow, well-defined purpose where both tools earn their place. No unrelated tools are present.

Completeness4/5

The core workflow is well covered: snapshot exposes the API surface, compare detects changes, recommends a bump, supports declared-version grading, and reports gate outcomes. Minor gaps may exist around CI integration or batch/multi-package workflows, but no obvious dead end for the stated purpose.

Maintenance

ActivityActive
ResponsivenessNo issues