stalemap
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITHUB_TOKEN | No | Token used when fetching changelogs and releases from GitHub (your `gh` login is used when available) | |
| STALEMAP_CACHE | No | Moves the cache directory (default is ~/.cache/stalemap) | |
| ANTHROPIC_MODEL | No | Model whose training cutoff is used when no --model is given | |
| STALEMAP_PRECOMPUTED_URL | No | Host serving precomputed reports; when set, package names (not versions) are sent to that host | |
| STALEMAP_GUARD_DEPRECATIONS | No | Set to 1 to have the guard also report deprecations, not just compile errors | 0 |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_changesA | Searches what changed in this project's dependencies since your training data, for the versions it has installed: removed, renamed and moved APIs, options and config keys, new required arguments, changed defaults and behavior, file conventions. Sources are the installed versions' type declarations, every release-note item since your training data and the packages' upgrade guides; each result says which. Call it BEFORE your first edit whenever the task touches a library's API or a config file, even for libraries you know well and even when you're sure: your training data predates these versions, and the API you remember may be gone. Also call it when a type error or warning names a package's API. Describe what you are about to do in your own words; old names are fine and often best. Good: 'resolve alias for a module in next.config', 'middleware that redirects with cookies', 'zod error message per parse', 'tsconfig baseUrl paths aliases', 'mongoose pre save hook next'. Bad (too vague): 'config', 'errors'. Keep one topic per call; call again for another. Do not call it more than 4 times for one question. |
| package_changesA | Before writing or changing code that calls a third-party npm package, call this to learn which of its APIs changed after your training cutoff: removed or renamed exports, new required parameters, removed options, deprecations with replacements, and breaking changelog entries. Pass the version the project pins (from package.json or the lockfile) when you know it. |
| project_changesA | Scan a JavaScript/TypeScript project and list the dependencies it imports that changed after your training cutoff, with the specific API changes that affect this code. Use it at the start of a task in an unfamiliar project, or after dependencies were upgraded. |
| check_notesA | Check whether the project's stalemap notes block is missing or out of date for the current dependencies and model. Offline and fast. |
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 4 tools
search_changes, package_changes, and project_changes all report dependency API changes, which creates some overlap, but each has a distinct entry point (free-text topic, specific npm package, whole-project scan) and the descriptions give clear trigger conditions. The boundaries are mostly learnable, with only mild risk of picking the wrong one.
Three tools share the strong '_changes' family pattern (search/package/project_changes), and check_notes is a readable verb_noun name. The first word shifts between verb and noun, a minor inconsistency, but overall the convention is predictable.
Four tools is well-scoped for a focused domain (surfacing post-cutoff dependency changes). Each tool earns its place and none feels redundant or padded.
The surface covers the key entry points: topic search, package-specific lookup, project scan, and notes staleness check. The notable gap is that check_notes only reads staleness with no tool to create or refresh the notes block, though that may be handled elsewhere.