pkgtruth
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PKGTRUTH_RETRIES | No | Retries for 429/5xx/network errors | 3 |
| PKGTRUTH_REGISTRY | No | Alternate registry | npm |
| PKGTRUTH_CACHE_DIR | No | Where adoption figures are cached | ~/.cache/pkgtruth |
| PKGTRUTH_TIMEOUT_MS | No | Per-request timeout | 8000 |
| PKGTRUTH_DISK_TTL_MS | No | How long a cached figure stays usable | 21600000 |
| PKGTRUTH_DOWNLOADS_API | No | Alternate downloads API | npm |
| PKGTRUTH_NO_DISK_CACHE | No | Set to 1 to disable the cache | |
| PKGTRUTH_MAX_CONCURRENCY | No | Override request pacing | per-host |
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 |
|---|---|
| check_packageA | Verify a single npm or PyPI package before installing, importing, or recommending it. Returns whether it actually exists, and flags slopsquatting (a low-adoption package impersonating a popular one), names npm removed for malware, install-time scripts, deprecation, and abandonment. Call this whenever you are about to introduce a dependency you have not verified in this session. Read-only; one or two requests to the public registry. A verdict of UNKNOWN means the registry did not answer — retry, never assume safe. |
| check_dependenciesA | Verify many npm or PyPI packages at once — use this before writing a package.json or requirements.txt, or handing a dependency list to a user. All names must belong to one ecosystem per call. Results are sorted worst-first so anything hallucinated or dangerous surfaces at the top. Read-only; batches registry requests and caches adoption figures, so 50 names take a few seconds. |
| check_install_commandA | Verify the packages a shell command would install or execute, before running it: |
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 has a clearly distinct scope: single package, multiple packages, and install command parsing. No overlap in purpose, and descriptions explicitly differentiate when to use each, eliminating ambiguity for the agent.
All three tools follow the consistent 'check_' + object pattern: check_package, check_dependencies, check_install_command. The verb is uniform and the object clearly indicates the target, making the naming predictable and intuitive.
With 3 tools, the server is tightly scoped to package verification and covers the essential granularity levels (single, bulk, command). Each tool serves a distinct need without redundancy, and the small count feels intentional rather than incomplete.
The tool surface covers the full workflow of package verification: checking individual packages, checking dependency lists before manifest creation, and validating install commands. The descriptions also handle edge cases like bare installs and lockfile usage, indicating thoughtful coverage with no obvious gaps.