Pinright
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 |
|---|---|
| find-libraryA | Finds the registry package for a library name ("next.js" -> npm:next, "pytorch" -> pypi:torch) and returns ids for get-docs, with the newest version that has no known advisories (safe) and a verdict. Skip it when you know the registry name: get-docs takes "npm:next" or "pypi:requests" directly, and check-packages takes plain names. |
| get-docsA | Returns the documentation sections that answer your question, taken from the package at a specific version (its published files and its repo at the release tag) and the project site. Without a version it documents the newest version with no known advisories. With a vulnerable version it starts with a SECURITY NOTICE and documents the safe version on the same release line, so the code you write keeps working after the upgrade. |
| check-packageA | Supply-chain verdict for one package, no docs: known advisories (CVE/GHSA, malware), deprecation, license, newest version with no known advisories, the safe version on the same release line as the one you pass, and typosquat lookalikes. For several packages use check-packages, one call for the whole list. |
| check-packagesA | Supply-chain verdict for up to 50 packages at once: one table row per package (verdict, version to pin, short reason) and the full notice only for the ones that need attention. Call it once with every dependency you plan to add, before writing the manifest, instead of one check per package. Packages already in the project are checked at their installed version when you omit it. |
| check-manifestA | Audits every package in a lockfile (direct and transitive) against OSV, the way Dependabot would, and says how to fix each finding: the direct upgrade on the same release line, the parent upgrade that clears a transitive one, or an override. Pass a project directory or a file path, or the file content with its name. Supported: package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, yarn.lock, package.json, requirements.txt, poetry.lock, uv.lock, pdm.lock, pyproject.toml, Cargo.lock, Cargo.toml, go.mod, Gemfile.lock, packages.lock.json, gradle.lockfile, pom.xml, build.gradle, build.gradle.kts, libs.versions.toml, composer.lock, composer.json, requirements*.txt. Without a lockfile the tree is resolved through deps.dev. GitHub workflows (.github/workflows/*.yml, action.yml, or the directory) get an Actions check: advisories and SHA pinning. |
| upgrade-guideA | Breaking changes, removed or renamed APIs, config and default changes, packages that split off, deprecations, and the advisories fixed, between the version a project uses and the one to move to. Sources: changelogs and GitHub release notes for the versions in between, migration guides when a major is crossed, and (npm) a diff of the exported .d.ts API. Call it before upgrading across a major, when a SECURITY NOTICE recommends a new major, or to fix a Dependabot PR. Without "to" it uses the version pinright recommends. |
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 6 tools
Each tool maps to a distinct workflow step: name resolution, documentation lookup, migration guidance, manifest audit, single-package verdict, and batch-package verdict. The descriptions explicitly distinguish check-package from check-packages and clarify when find-library can be skipped because get-docs accepts registry-qualified ids directly.
All tools use kebab-case and mostly follow a verb_noun pattern (find-library, get-docs, check-manifest, check-package). The only minor deviation is upgrade-guide, which reads more like a noun compound, but overall the naming is predictable and readable.
Six tools is well-scoped for a package supply-chain and documentation server. Each tool has a clear role, and the batch check-packages tool prevents the count from being unnecessarily inflated by per-dependency checks.
The surface covers resolving package names, retrieving docs, planning upgrades, auditing lockfiles and GitHub workflows, and checking one or many packages for advisories. No obvious lifecycle step for supply-chain safety or package documentation is missing.