unripe
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GOPROXY | No | For Go, unripe uses the first proxy in GOPROXY. Point it at your own proxy for private Go modules. | |
| GOSUMDB | No | Go checksum database setting, honoured by unripe. | |
| NO_PROXY | No | Hosts that should bypass the proxy. | |
| GONOSUMDB | No | Go checksum database exclusion setting, honoured by unripe. | |
| GOPRIVATE | No | Go private module setting, honoured by unripe; private modules fall back to the commit time. | |
| HTTPS_PROXY | No | Proxy used for outbound requests when behind a corporate proxy. | |
| GITHUB_TOKEN | No | Set to get past GitHub's limit of 60 requests an hour when dating GitHub Actions. | |
| UNRIPE_CACHE | No | Directory where publish times are cached on disk forever (default is ~/.cache/unripe, or %LOCALAPPDATA%\unripe\cache on Windows). | |
| SSL_CERT_FILE | No | Path to a company CA bundle to use for TLS verification. | |
| UNRIPE_CONFIG | No | Reads the config file named in UNRIPE_CONFIG instead of the default .unripe.toml or [tool.unripe] in pyproject.toml. | |
| UNRIPE_PYPI_URL | No | PyPI mirror URL to use instead of the default. | |
| UNRIPE_CA_BUNDLE | No | Path to a company CA bundle to use for TLS verification. | |
| REQUESTS_CA_BUNDLE | No | Path to a company CA bundle to use for TLS verification. | |
| UNRIPE_MAVEN_REPOS | No | Comma separated list of Maven repositories to add, the same way maven-repositories does in the config. | |
| UNRIPE_CONAN_REMOTE | No | Conan remote to use (any server with Conan's v2 API) instead of the default. | |
| UNRIPE_NPM_REGISTRY | No | npm registry mirror to use instead of the default. |
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 |
|---|---|
| check_packageA | Say when a package version was published and whether it is old enough under the project's minimum age. Leave version out to list recent releases and get the newest version that is old enough: use that version when adding or upgrading a dependency. A version that is too new comes with the newest older version that passes. |
| check_lockfilesA | Check every lockfile under a directory (package-lock.json, pnpm-lock.yaml, yarn.lock, bun.lock, deno.lock, uv.lock, poetry.lock, requirements.txt, Cargo.lock, go.mod, composer.lock, Gemfile.lock, packages.lock.json, gradle.lockfile, pubspec.lock, Podfile.lock, Package.resolved, .terraform.lock.hcl, conan.lock, renv.lock, mix.lock, flake.lock, MODULE.bazel.lock, vcpkg.json and more) and report every locked version that is younger than the minimum age or whose age is unknown. Set since to a git ref, like origin/main, to check only what changed since then. |
| cooldown_settingsA | Show the unripe policy for a directory, the minimum release age settings its package managers and update bots already have (npm, pnpm, yarn, bun, uv, Poetry, Deno, Cargo, Bundler, Dependabot, Renovate), where they disagree, and the lines that would add the missing ones. |
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 3 tools
Each tool targets a clearly different object: project configuration/policy, a single package version, and lockfiles across a directory. Their boundaries are easy to infer, and an agent should not confuse checking one package with scanning all lockfiles or reading cooldown settings.
All names use snake_case, and two follow a clear verb_noun pattern (check_package, check_lockfiles). cooldown_settings is a noun phrase rather than a verb-led name, but it remains readable and semantically clear.
Three tools is well scoped for a focused minimum-release-age auditing server. Each tool has a distinct role: inspect settings, inspect one package, and inspect lockfiles.
The server covers policy inspection and two important audit paths, but there is no remediation or bulk upgrade tool to fix lockfiles or manifests. Agents can likely work around this manually, but the lifecycle stops short of applying compliant versions.