List recent released versions of a package with release dates (most recent first). Helps an agent pick a version or check how actively it is maintained. 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. | |
| limit | No | Maximum number of results to return. | |
| 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, the description carries the burden and does state the key behavior: output is a list of versions with dates, sorted most recent first. However, it doesn't disclose error behavior, what happens for unknown packages, or the exact output shape, which are relevant for an unannotated tool.
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?
Three short sentences: core action, purpose, and supported ecosystems. It is front-loaded with the main behavior in the first sentence and contains no filler.
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 has no output schema and no annotations, so the description must cover enough for correct invocation. It covers purpose, sorting, and ecosystems, and the schema handles parameters, but it omits error cases and any return-format details beyond 'release dates,' leaving minor gaps.
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 description coverage is 100%, so the description doesn't need to add parameter detail. It does reiterate the ecosystem enum and package-name semantics implicitly, but that's already in the schema; no extra semantic value is added.
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 uses the specific verb 'List' with a clear resource ('recent released versions of a package with release dates') and adds ordering ('most recent first'), which immediately distinguishes the tool from siblings like package_dependencies or package_downloads. It also states the supported ecosystems, so there's no ambiguity about scope.
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?
It frames when the tool is useful: 'Helps an agent pick a version or check how actively it is maintained,' which gives a clear context for invocation. It doesn't explicitly mention exclusions or alternative tools, but the use-case framing is enough to route an agent to this tool for version-related queries.
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.