Dev-registry data: npm/PyPI/Docker/VS Code packages, dep graphs, vulns, 50+ ecosystems.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 10 of 10 tools scored.
Most tools have clear, distinct purposes, but get_package and get_ecosystems_package both return package metadata and could be confused; search_ecosystems and search_packages also share a similar naming pattern though their behavior differs (exact cross-registry lookup vs fuzzy within a registry). Overall, descriptions help disambiguate.
All tools follow a consistent verb_noun pattern: get_ for fetching specific data, search_ for searching. No mixed conventions or vague verbs, making the API predictable.
10 tools is well-scoped for a package/dependency intelligence server. Each tool covers a distinct aspect (metadata, versions, dependencies, downloads, vulnerabilities, insights, search) without feeling bloated or thin.
The tool surface covers core package lookups, version listing, dependency graphs, download stats, vulnerabilities (single and batch), and security insights. Minor gaps exist, such as no direct tool for comparing packages or listing maintainer info, but these are not essential for the stated purpose.
get_dependency_graphGet resolved dependency graphAThe fully resolved dependency graph for one exact package version, via deps.dev. Returns a flat nodes[] array plus integer-index edges[] (walk from/to to rebuild the tree). Each node carries relation (self | direct | indirect) and a direct boolean; node[0] is always the queried root (relation: self). Node order is NOT stable — look nodes up by name/relation, never by positional index. system is case-insensitive and lowercased (npm, pypi, cargo, go, maven, nuget). version is REQUIRED (a graph is resolved for one exact version).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name / id. | |
| system | Yes | Package system / ecosystem for deps.dev. Case-insensitive, lowercased server-side. | |
| version | Yes | Exact version to resolve (e.g. 18.2.0). Required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by detailing the return format (flat nodes[], integer-indexed edges[]), the stable root node (node[0] with relation: self), and the critical caveat that node order is NOT stable and must be looked up by name/relation. It also clarifies system case-insensitivity and the requirement for version, adding valuable behavioral context beyond the readOnly/idempotent hints.
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, front-loaded with the purpose, then packed with essential behavioral details. Every sentence earns its place; there is no filler or redundancy. The structure efficiently communicates the return format, node/edge semantics, and important caveats without being bloated.
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?
For a tool with no output schema, the description thoroughly explains the return structure (nodes, edges, relation, direct boolean), the root node convention, the unstable ordering, and parameter constraints. It covers all functional aspects an agent needs to invoke the tool and interpret results, making it highly complete given the tool's complexity.
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% with each parameter already described. The description adds emphasis on version being required and system being case-insensitive, but these are largely restatements of the schema constraints. It doesn't substantially enrich parameter meaning beyond what the schema provides, so the baseline 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 clearly states it returns 'the fully resolved dependency graph for one exact package version' via deps.dev, which is a specific and unambiguous purpose. It distinguishes itself from sibling tools (downloads, versions, vulnerabilities) by focusing on the graph structure with nodes and edges.
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 makes clear the tool is for resolving a dependency graph for a single exact version, and explicitly notes version is required. It doesn't provide explicit exclusions or alternatives, but the context of being a graph resolution tool is clear given the sibling tools and the emphasis on one exact version.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_downloadsGet download / pull statisticsADownload statistics for a package. Only npm (via api.npmjs.org) and PyPI (via pypistats.org) support this; any other registry returns 400 not_supported. npm returns a period window with downloads, start, and end; PyPI returns last_day, last_week, and last_month totals.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name. | |
| registry | Yes | Target registry. Only npm and pypi expose download stats. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnly/idempotent/destructive hints, but do not cover error behavior or return shapes. The description adds concrete details: exact API endpoints, the 400 error for unsupported registries, and the distinct response formats for npm vs PyPI.
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 sentences, front-loaded with the core action, then constraints and return formats. Every sentence provides essential information without redundancy or 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?
With only two simple parameters and no output schema, the description fully covers supported registries, error handling, and return shape variations. It provides all necessary operational context for an agent to select and call the tool correctly.
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 covers both parameters with 100% coverage, so baseline is 3. The description adds value by explaining how the registry parameter affects the response structure (period window vs last_day/week/month totals), which goes beyond the schema's simple type/enum descriptions.
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 states 'Download statistics for a package' – a clear verb+resource with scope. It further distinguishes from siblings by detailing registry-specific behavior and supported APIs.
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 explicitly states that only npm and PyPI are supported, and that any other registry returns 400 not_supported, which sets clear usage boundaries. It does not explicitly name alternative tools, but the stated purpose differentiates it from sibling package tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ecosystems_packageGet one package on one registry (with reverse-dep counts)AFull normalized metadata for one package on one of 50+ registries, via ecosyste.ms — including the fields v1 registries can't give you: dependentReposCount and dependentPackagesCount (reverse dependencies), ecosystem, and vulnerabilityCount. Scoped/namespaced names are handled automatically. Returns 404 if the package does not exist on that ecosystem.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name / id. | |
| ecosystem | Yes | Target ecosyste.ms ecosystem slug (e.g. npm, pypi, cargo, rubygems). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral details: scoped/namespaced names are handled automatically, and a 404 is returned for missing packages, which goes beyond the annotations.
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, front-loaded with the main purpose, and every phrase adds value. No redundant information or excessive length.
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?
For a single-package getter with no output schema, it covers the key return fields, the source service, and error behavior. It doesn't describe the exact JSON format, but this is not critical for a simple read operation.
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%, and the description adds extra meaning to the 'name' parameter by clarifying that scoped/namespaced names are handled automatically, reducing ambiguity about how to pass them.
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 clearly states the tool retrieves full normalized metadata for one package on one of 50+ registries via ecosyste.ms. It highlights unique fields like dependentReposCount and dependentPackagesCount, distinguishing it from basic v1 registry retrieval tools.
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 provides clear context for when to use this tool (when you need ecosyste.ms metadata, reverse-dependency counts, etc.) and implicitly contrasts with v1 registries. However, it doesn't explicitly name alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_insightsGet project insights — OSSF Scorecard + repo signalAHealth and security insights for a package's source project, via deps.dev. Returns the linked source repository, GitHub stars/forks/openIssues, licenses, resolved dependencyCount, security advisories, and the full OSSF Scorecard (ossfScore 0..10 plus the per-check breakdown). Omit version to use the registry default version — note deps.dev's default is a MOVING target and an unverified default mirror may have no computed scorecard (ossfScore: null); pin version for a stable, scorecard-backed result. system is lowercased (npm, pypi, cargo, go, maven, …).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name / id. | |
| system | Yes | Package system / ecosystem for deps.dev. Case-insensitive, lowercased server-side. | |
| version | No | Exact version. Omit for the (moving) registry default version. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral caveats beyond the schema—the moving registry default, possible null ossfScore on unverified mirrors, system case-lowering, and resolved dependencyCount. This enriches the agent's expectations without contradicting annotations.
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 dense sentences deliver purpose, return fields, and critical usage caveats with no filler. Every sentence earns its place, and the most important operational warning (version pinning) is emphasized inline.
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?
Despite having no output schema, the description enumerates the main return fields, notes the null-scorecard edge case, and covers optional parameter behavior. Combined with rich annotations and fully described parameters, this gives an agent enough context to invoke the tool correctly.
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 baseline is 3. The description goes further by explaining the semantics of omitting version (moving target, potential null scorecard) and clarifying that system is lowercased server-side, adding real value over the raw schema.
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 specifies the exact resource ('project insights') and enumerates concrete outputs (OSSF scorecard, repo stars/forks, advisories), making it clearly distinct from sibling tools like get_vulnerabilities or get_package. The verb 'Get' is paired with a well-scoped resource, earning full credit for purpose clarity.
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?
Clear context is provided: this tool gives health/security insights for a package's source project via deps.dev, with specific guidance on pinning versions for a stable scorecard. It does not explicitly name alternatives or when-not cases, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_packageGet normalized package detailsAFull normalized details for one package by registry + name, in a single unified Package shape across npm, PyPI, Docker Hub, and the VS Code Marketplace. name handles scoped npm ids (e.g. @types/node), Docker namespaces (e.g. library/nginx or a bare nginx for official images), and VS Code publisher.extension ids. With registry=all the request fans out to every registry in parallel and returns a packages array (missing registries are silently dropped); otherwise a single package is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name / id. Supports scoped npm ids (@scope/pkg), Docker namespaces (ns/name or a bare name for official images), and VS Code publisher.extension ids. | |
| registry | Yes | Target registry. "all" fans out to every registry and merges results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, openWorld, idempotent), the description discloses valuable behaviors: parallel fan-out with registry=all, returning an array vs. a single package, and silently dropping missing registries. It also describes the unified Package shape across registries, giving the agent a clear model of what will happen. This exceeds what annotations alone provide.
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 three sentences with a front-loaded clear purpose. Every sentence adds essential context: unified shape, name format handling, and behavior of registry=all. No filler or redundancy, making it easy to parse quickly.
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?
Given the tool's complexity (multi-registry, variable output shape) and no output schema, the description explains the return shape for both modes (single vs. array), the unified shape, and edge cases (missing registries dropped). It covers name formats for all registries, making it sufficiently complete for an agent to invoke correctly.
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 covers both parameters 100%, including name format details and registry enum. The description largely restates this information with examples but adds no significant new meaning beyond the schema. Behavioral notes like 'missing registries are silently dropped' relate to output, not parameter semantics. Since schema coverage is high, a baseline 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 states a clear, specific purpose: 'Full normalized details for one package by registry + name' with a unified Package shape. It explicitly distinguishes itself from sibling tools by covering multiple registries and a unified output shape, so the agent knows exactly what this tool provides versus alternatives like get_downloads or get_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 clearly implies usage for retrieving normalized package details across registries, with explicit notes on the registry parameter behavior. It does not explicitly state 'use this instead of X', but the context is unambiguous and differentiates from siblings. A 4 is appropriate because exclusions or when-not-to-use are not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_versionsGet published versions / tagsAList published versions (npm/PyPI), image tags (Docker Hub, most recent 25), or extension versions (VS Code) for a package. registry=all is NOT supported here — pick a single registry. Each item carries version and released, plus registry-specific extras (files for PyPI, size for Docker tags).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name / id (scoped npm ids, Docker namespaces, and VS Code publisher.extension ids supported). | |
| registry | Yes | Target registry. "all" is not supported here — pick one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds useful behavioral constraints such as 'registry=all is NOT supported here' and mentions the 25-tag limit for Docker Hub, plus registry-specific extras in the output, which goes beyond annotations.
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, front-loaded with the main action, then a critical constraint, and finally a summary of output contents. Every sentence earns its place with no redundancy or fluff.
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?
With two parameters and no output schema, the description provides a solid overview: supported registries, the 'all' limitation, and what each item contains. It could be more explicit about pagination for non-Docker registries, but for a simple list tool, it covers the essential usage context.
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% with descriptive fields for both 'name' and 'registry'. The description adds minimal new parameter-level information, mostly reinforcing that a single registry must be chosen, which is already implied by the enum. The output details (extras) are more about return values than parameters.
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 clearly states the tool lists published versions for npm/PyPI, image tags for Docker Hub, and extension versions for VS Code. It distinguishes itself from sibling tools by focusing specifically on version/tag enumeration, and even clarifies that 'registry=all' is not supported, making the purpose unambiguous.
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 provides clear context on when to use the tool (list versions/tags for a package) and explicitly instructs to pick a single registry. However, it does not explicitly contrast with alternatives like get_package or get_downloads, so it lacks a full 'when-not-to-use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_vulnerabilitiesGet vulnerabilities for a packageAKnown vulnerabilities (CVE / GHSA / PYSEC / GO advisories) for a package, via OSV.dev. Pass version to filter to advisories affecting that exact version, or omit it for the package's full advisory history. Each result carries the OSV id, cross-id aliases, a severity word grade (LOW|MODERATE|HIGH|CRITICAL), the cvss vector string, affectedRanges with fixed-version events, references, and cwes. A clean package returns count: 0 with an empty list (not an error). ecosystem is CASE-SENSITIVE — use OSV's spelling (npm, PyPI, Go, crates.io, Maven, NuGet, RubyGems, …). Use scan_vulnerabilities_batch for lockfile batch scans.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name. | |
| version | No | Exact version to filter advisories to. Omit for full history. | |
| ecosystem | Yes | OSV ecosystem, CASE-SENSITIVE (e.g. npm, PyPI, Go, crates.io, Maven, NuGet, RubyGems). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses detailed behavioral traits beyond annotations: a clean package returns count: 0 with an empty list (not an error), ecosystem is case-sensitive with examples, and results include specific fields. The description adds substantial value, enhancing the agent's understanding of output and edge cases.
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 well-structured and front-loaded with the core purpose, followed by parameter behavior, output details, edge cases, and alternatives. Every sentence adds value without fluff, balancing detail with conciseness.
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?
Given the absence of an output schema, the description fully documents return contents, edge cases, and usage constraints. It covers all necessary aspects for correct invocation and interpretation, making it highly complete.
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% and parameter descriptions are already clear. The description reinforces parameter semantics by explaining the version filter behavior and case-sensitivity of ecosystem, but adds only slightly beyond the schema. Still, it provides useful context for how parameters affect results.
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 clearly states the tool's function: retrieving known vulnerabilities for a package from OSV.dev. It specifies the verb 'get', the resource 'vulnerabilities', and the package scope, making it distinct from sibling tools like get_package or scan_vulnerabilities_batch.
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?
Explicitly explains when to omit vs. pass the version parameter for filtering, and directs users to scan_vulnerabilities_batch for lockfile batch scans. This provides clear guidance on usage scenarios and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_vulnerabilities_batchBatch vulnerability scan (lockfile)AScan many packages in one call — ideal for a whole lockfile. Pass a queries[] array (max 100) of { ecosystem, name, version? }; results are returned positionally aligned, one row per query, each with a count and a hydrated vulns[] array. Advisories are de-duplicated and hydrated across the batch. ecosystem is CASE-SENSITIVE (OSV spelling).
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | Up to 100 { ecosystem, name, version? } queries, ideal for a whole lockfile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already declare readOnly, idempotent, and non-destructive, the description adds critical behavioral details: positional alignment of results, de-duplication and hydration of advisories, and case-sensitive ecosystem values. These go beyond the annotations and are essential for correct invocation.
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 three sentences, each delivering distinct value: purpose, input/output structure, and a key caveat. It is front-loaded with the primary use case 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?
With no output schema, the description must explain return values. It does outline positional rows with count and hydrated vulns[], and mentions de-dup, but leaves details like count semantics and exact vuln fields ambiguous. For a batch tool of moderate complexity, this is adequate but not exhaustive.
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 baseline is 3. The description does not significantly add to parameter meaning; it repeats max 100 and case-sensitivity. It does describe the query object shape, but there is a slight ambiguity: it lists ecosystem without a question mark while the schema only requires name, which could confuse on requiredness.
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 clearly states 'Scan many packages in one call' with a specific verb and resource, and explicitly positions it as ideal for lockfiles. This distinguishes it from the sibling get_vulnerabilities tool, which handles single package scans.
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 provides strong usage context ('ideal for a whole lockfile') and parameters (max 100 queries). It does not explicitly mention alternatives or when not to use it, but the lockfile focus makes the intended scenario clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_ecosystemsCross-registry package lookup (50+ ecosystems)ALook a package name up across 50+ registries at once, via ecosyste.ms. This is an EXACT-name lookup (not fuzzy full-text): q=react returns the react package everywhere it exists (npm, cargo, nuget, pub, bower, …), each as a normalized ecosystemsPackage with reverse-dependency counts. Pass ecosystem to narrow to one registry. Results carry dependentReposCount, dependentPackagesCount, and vulnerabilityCount.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Exact package name to look up across registries. | |
| limit | No | Max results. Clamped to 1-50. Default 20. | |
| ecosystem | No | Narrow to one ecosystem (e.g. pypi, npm, cargo). Omit to search all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the description adds useful context about exact-name matching and the shape/counts of results. It discloses that results carry dependentReposCount, dependentPackagesCount, and vulnerabilityCount, which supplements the schema. No contradictions with annotations.
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 sentences, front-loaded with the core action, and every sentence adds value: scope, exact-match behavior, narrowing option, and result contents. No filler or redundancy.
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?
With no output schema, the description adequately explains the return shape (normalized package with counts) and the key behavior. It covers exact matching, cross-registry scope, optional ecosystem filtering, and result fields, making it complete for context.
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 baseline is 3, but the description adds meaningful examples (q=react) and clarifies each result is a normalized ecosystemsPackage with reverse-dependency counts. It enriches understanding of q and ecosystem beyond the schema definitions.
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 a specific verb phrase ('Look a package name up across 50+ registries at once') and clearly identifies the resource (ecosyste.ms) and scope. It distinguishes itself from siblings by emphasizing exact-name lookup across many ecosystems, which is unique among the listed tools.
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 provides clear context for when to use the tool (cross-registry lookup) and explicitly notes it is exact-match, not fuzzy full-text, which helps choose over sibling search tools. It also explains how to narrow results with the ecosystem parameter, though it does not explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_packagesSearch packages across registriesASearch a registry for packages matching q. registry=all fans out to npm, Docker Hub, and the VS Code Marketplace and merges the results. PyPI has no public search API, so registry=pypi returns 400 not_supported — look a PyPI package up by name via get_package instead. Results are normalized PackageSummary items (npm adds a relevance score; Docker adds isOfficial).
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query. | |
| limit | No | Max results per registry. Clamped to 1-50. Default 20. | |
| registry | Yes | Target registry. "all" fans out to npm, Docker, and VS Code and merges results. pypi returns not_supported. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds valuable behavioral context beyond annotations: the fan-out/merging behavior, PyPI's 400 not_supported error, and result normalization details (npm relevance score, Docker isOfficial). This fully discloses operational traits.
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 three sentences long, front-loaded with the core action, and every sentence contains distinct, necessary information (registry behavior, pypi fallback, result format). No wasted words; it earns its length.
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, but the description compensates by describing the normalized PackageSummary result structure and per-registry additions. The description covers error behavior, alternatives, and fan-out semantics, making it fully self-contained for an agent to invoke correctly.
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 baseline is 3. The description adds meaning to 'registry' by explaining the 'all' fan-out and the pypi error, and clarifies that q searches for matching packages. While the schema already documents enums and limits, the description provides operational context that the schema cannot.
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 a specific verb ('Search') and resource ('registry for packages') with a clear parameter ('q'). It distinguishes itself from sibling get_* tools by focusing on search rather than direct retrieval, and explicitly clarifies registry-scoped vs. cross-registry behavior.
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 provides explicit when-to-use guidance: it explains when registry=all is appropriate (fan out to three registries), and explicitly warns against using registry=pypi, directing users to get_package instead. This is a clear exclusion and alternative, which is exceptional guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.
