pkgintel-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | HTTP port. The listener is `127.0.0.1`. | 3000 |
| MCP_TRANSPORT | No | `stdio` or `http`. `--http` forces HTTP. | stdio |
| PKGINTEL_CONTACT | No | User-Agent mailto. Must look like an email. Never a personal address in the repo. | contact@example.com |
| PKGINTEL_PER_MINUTE | No | Inbound sliding window. Cache hits do not spend it. | 60 |
| PKGINTEL_TIMEOUT_MS | No | Per-attempt upstream timeout. | 20000 |
| PKGINTEL_CACHE_TTL_SEC | No | TTL for a successful redacted upstream body. `0` disables the cache. | 60 |
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 |
|---|---|
| get_packageA | Look up a package across npm, PyPI, Cargo, Go, Maven, NuGet, or RubyGems via deps.dev. Returns versions, latest, licences, links, and deprecation. |
| get_versionA | Look up one exact package version on deps.dev. Returns licences, advisories, links, and SLSA or provenance when present. |
| get_dependenciesB | Return a depth-limited resolved dependency graph from deps.dev. Default depth is 2, max 4. |
| check_vulnerabilitiesB | Query OSV.dev for one package@version or a batch of packages. Partial source failure is reported per source. |
| audit_lockfileB | Parse package-lock.json v2/v3, pinned requirements.txt, Cargo.lock, or go.sum from text or a local path. Runs OSV querybatch and summarises licences found in the lockfile. |
| compare_packagesA | Compare 2 to 5 packages side by side. One failed package does not drop the others. |
| get_scorecardA | Fetch an OpenSSF Scorecard report for a GitHub repo, or resolve the repo from a package via deps.dev. |
| search_packagesA | Search npm or crates.io. PyPI has no search API. Other ecosystems need an exact name via get_package. |
| license_checkB | Evaluate an SPDX 2.x expression against an allow-list of SPDX identifiers. AND requires every branch. OR requires one. |
| list_sourcesA | List upstream sources, enforced rates, terms links, and whether PKGINTEL_CONTACT is set. Values are never returned. |
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 10 tools
Tools mostly target distinct resource+action pairs: get_package (package-level metadata), get_version (exact version), search_packages (discovery), and get_dependencies (graph) are clearly separable. The only soft overlaps are check_vulnerabilities vs audit_lockfile (both hit OSV) and license_check vs audit_lockfile's license summary, but the descriptions make the boundary between 'single/batch package query' and 'lockfile-level audit' clear enough.
Nine of ten tools follow a clean verb_noun snake_case pattern (get_*, check_*, audit_*, compare_*, search_*, list_*). The lone exception is license_check, which inverts to noun_verb, a minor but noticeable deviation in an otherwise uniform set.
Ten tools is well within the ideal 3-15 range and every tool maps to a distinct capability of a package-intelligence service (lookup, deps, vulns, lockfile audit, comparison, scorecard, search, license, sources). No filler tools are present.
The surface covers the core lifecycle: discovery (search_packages), identity (get_package/get_version), dependency resolution, vulnerability scanning, lockfile auditing, comparison, scorecard health, and license policy. Minor gaps remain — no SBOM/export output, no version-range resolution or upgrade-path suggestion, and no direct advisory detail lookup by ID — but agents can work around these via the existing tools.