packagerating MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PACKAGERATING_API_KEY | Yes | Your packagerating.com API key |
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 |
|---|---|
| list_packagesA | List npm/PyPI packages that have at least one score, sorted by composite score by default. |
| get_packageA | Get the full health/risk score for a single package by name. If the package has never been scored, this triggers a crawl and waits (bounded) for it to finish before returning. |
| request_crawlA | Enqueue one or more packages for crawling without waiting for the result. Useful for pre-warming several packages at once, e.g. before comparing alternatives. |
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 distinct purpose: listing scored packages, fetching a single package's score, and enqueueing crawls without waiting. Although get_package can trigger a crawl, the key difference is that request_crawl is for background pre-warming, so there is no ambiguity.
All tool names follow the same verb_noun pattern: list_packages, get_package, request_crawl. The naming is predictable and consistently formatted.
With only 3 tools, the server is tightly scoped to its purpose of providing package ratings. Each tool is necessary and there is no bloat, making the count feel intentional rather than thin.
The tool surface covers the core workflows: listing available packages, retrieving detailed scores, and requesting background crawls for pre-warming. There are no obvious operational gaps for the stated domain.