Get core metadata for a package: latest version, description, license, homepage, source repository, maintainers, and whether it is deprecated. Use before an agent installs or recommends a dependency. Ecosystems: npm, pypi, cargo.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package/crate name | |
| 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?
Without annotations, the description carries behavior disclosure; 'Get' and the field list make it clear this is a read-only metadata lookup. However, it does not mention error behavior (e.g., package not found), live data, or any limits, and no annotations back up the safety profile.
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, with the action and key output front-loaded, followed by a usage cue and ecosystem list. No redundant or filler text.
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?
Returned fields are enumerated in lieu of an output schema, so an agent knows what it will get. It lacks only minor behavioral details like not-found handling, but the combination of param schema, field list, and usage context is sufficient for this simple tool.
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?
Input schema already documents both parameters fully (name and ecosystem with enum), and the description only repeats 'Ecosystems: npm, pypi, cargo.' The field list relates to output, not parameter semantics, so description adds no extra parameter value.
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?
States a clear verb and resource ('Get core metadata for a package') and itemizes the exact fields (latest version, description, license, etc.). This distinguishes it from sibling tools focused on dependencies, downloads, health, search, and 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?
'Use before an agent installs or recommends a dependency' gives explicit context for when to call. It does not name sibling alternatives or state when not to use it, but the guidance is unambiguous enough.
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.