Get popularity/download statistics for a package (recent download counts). Useful for judging how widely used and battle-tested a dependency is. Ecosystems: npm, pypi, cargo.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact package name as published in that registry, e.g. express for npm, requests for pypi, serde for cargo. | |
| ecosystem | Yes | Package registry to look in. One of: npm, pypi, cargo. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose that this is a read-only statistics lookup returning recent download counts, which is the core behavior. However, it does not specify the exact time window, aggregation level, or whether any limits or caveats apply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the core function, followed by a useful real-world use case and supported ecosystems. Every sentence adds value, with no filler or repetition beyond the brief ecosystem list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema fully documents required parameters, but there is no output schema and no annotations. The description gives a general sense of the return value ('recent download counts') but lacks detail on time range or exact output format, which leaves some ambiguity for interpreting results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters with examples and the enum for ecosystem. The description repeats the ecosystem list but adds no meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'Get popularity/download statistics for a package,' and clarifies the data as 'recent download counts.' This clearly distinguishes the tool from siblings like package_dependencies, package_health, and package_versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: judging how widely used and battle-tested a dependency is. It does not explicitly name alternatives or state when not to use this tool, but the context is strong enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool maps to a clearly identifiable package-intelligence task—search, metadata, versions, dependencies, downloads, or health. The only real overlap is between package_health and package_info, since health includes deprecation status, license, and maintainer data that also appear in info, but the composite vs. core-metadata framing keeps them distinguishable.
Every tool follows the same package_<noun> pattern, making the API surface predictable and easy to navigate. The nouns are all simple, descriptive, and consistent in style.
Six tools is well-scoped for a package intelligence server; each tool addresses a distinct facet of evaluating a dependency. There is no bloat or redundancy that would make the set feel heavy.
The set covers the core package evaluation workflow: discover via search, inspect metadata and versions, understand dependencies, gauge popularity, and get a health/advisory summary. Minor gaps exist, such as no transitive dependency traversal or ecosystem-wide comparison, but agents can still make solid dependency decisions with the provided tools.