Search for packages by keyword and get the top matches with descriptions. Supported ecosystems: npm and cargo (PyPI has no public search API).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. | |
| query | Yes | Free-text search terms, matched against package names and descriptions. | |
| 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?
No annotations are present, so the description must carry the transparency burden. It clearly discloses the core search behavior and the ecosystem limitation, but it does not explain result ranking, sorting, pagination, or the exact return shape beyond 'descriptions', leaving some behavioral aspects implicit.
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?
Two short sentences front-load the purpose and then provide a precise scope limitation. Every sentence adds information, and the parenthetical about PyPI prevents invalid calls without extra words.
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, but with no annotations and no output schema, the description should specify more about result structure and ordering. It covers scope and supported ecosystems, yet omits return fields, ranking behavior, and behavior on no matches, and the schema's contradictory ecosystem description introduces some confusion that the description only partially mitigates.
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 has 100% parameter coverage, so baseline is 3. The description adds value by resolving a contradiction in the ecosystem parameter: the schema says 'One of: npm, pypi, cargo' while the enum only allows npm/cargo; the description explicitly clarifies that PyPI is unsupported and explains why. It also frames query as keyword search, reinforcing the schema's free-text description.
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 names a specific action ('Search'), a resource ('packages'), and a concrete output ('top matches with descriptions'). It also explicitly states the supported ecosystems (npm/cargo) and why PyPI is excluded, clearly separating it from sibling tools that retrieve dependencies, downloads, health, info, or 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 implies use when searching npm/cargo packages and gives an explicit when-not for PyPI ('PyPI has no public search API'). However, it does not contrast this tool with sibling tools or state when to prefer e.g. package_info for details, so routing to alternatives is left to inference.
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.