installed-version-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NPM_REGISTRY | No | Registry for the optional latest-version drift check. | https://registry.npmjs.org |
| INSTALLED_VERSION_PROJECT | No | Default project root (folder with package.json). Overridable per call via projectDir. | server cwd |
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 |
|---|---|
| installed_versionA | Report the EXACT version of a dependency that is installed in the current project right now — read from node_modules (authoritative) or the lockfile — plus the range declared in package.json and, if online, how far behind npm's latest it is. Reach for this BEFORE writing code against a library: the model's training blends many versions and guesses APIs that don't exist in the installed one. Ground on THIS number instead. Set the project with the projectDir arg or the INSTALLED_VERSION_PROJECT env var. |
| resolve_importsA | Given the packages you are ABOUT TO import in a file, return the exact installed version of each in this project. Use this at the start of writing/editing a file so every library call is grounded on the version really present. Pass bare import specifiers (e.g. 'react-router-dom', '@aws-sdk/client-s3'); subpaths are normalized to the package. |
| project_versionsA | List every dependency's installed version in this project (from the lockfile), optionally filtered by a substring. Use to audit what's actually present, or to answer 'what version of X is in here' across the whole tree including transitive deps. |
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
The three tools are largely distinct: installed_version targets a single dependency with detailed context, resolve_imports handles a batch of imports, and project_versions provides a full project-wide audit. Minor overlap exists between installed_version and resolve_imports when checking specific packages, but the singular/batch distinction and differing output detail make boundaries clear.
All names use snake_case, but the structure is inconsistent: installed_version is adjective_noun, resolve_imports is verb_noun, and project_versions is noun_noun. A more consistent verb_noun pattern (e.g., get_installed_version, resolve_versions, list_versions) would improve predictability.
With 3 tools, the server is well-scoped for its narrow purpose of reporting installed dependency versions. Each tool earns its place: one for single-package detail, one for import-time grounding, and one for full-project auditing.
The tool surface covers the domain comprehensively: specific version lookup (installed_version), batch lookup for imports (resolve_imports), and all installed versions including transitive deps (project_versions). No obvious gaps exist for the stated purpose of grounding on installed versions.