Detect malicious or vulnerable npm packages: registry search, OSV.dev and GitHub advisory lookups
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.1/5 across 6 of 6 tools scored.
Each tool targets a distinct task: batch vs single vulnerability queries, package metadata at latest vs specific version, advisory listings, and search. The purpose of each is clear and unambiguous from the names and descriptions.
All tool names follow a consistent verb_noun pattern in snake_case: batch_query_vulnerabilities, get_latest_advisories, get_package, get_package_version, query_vulnerabilities, search_packages. The verbs vary but the structure is uniform and predictable.
With 6 tools, the set is well-scoped for an npm security analysis server. Each tool covers a necessary operation without redundancy or bloat, fitting comfortably within the ideal 3-15 range.
The server covers search, package metadata (latest and specific versions), vulnerability queries (single and batch), and advisory listings. A minor gap is the lack of a tool to fetch details for a specific advisory by ID, but core workflows are fully supported.
batch_query_vulnerabilitiesBatch query known vulnerabilitiesAQuery OSV.dev for known vulnerabilities across up to 100 npm packages at once — ideal for scanning a whole package.json/lockfile in one call.
| Name | Required | Description | Default |
|---|---|---|---|
| packages | Yes | 1-100 packages to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read-only operation (readOnlyHint=true, destructiveHint=false) and open-world semantics. The description adds that the query targets OSV.dev and supports one-call batch scanning, but does not disclose external service dependencies or rate limits. This is acceptable given 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 a single, front-loaded sentence that efficiently conveys the purpose, scale, and ideal use case without 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?
For a simple batch-query tool with a fully described schema, safe read-only annotations, and no output schema required in the description, the provided description is complete and informative. It covers the key differentiator of batch scanning and typical use case.
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?
The schema fully documents the only parameter 'packages' with descriptions, min/max items, and structure. The description adds little beyond 'up to 100', which is already in the schema, so it aligns with the baseline for full schema coverage.
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 queries OSV.dev for vulnerabilities across up to 100 npm packages, with a specific verb and resource. It effectively distinguishes itself from the sibling tool 'query_vulnerabilities' by emphasizing batch scanning.
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 phrase 'ideal for scanning a whole package.json/lockfile in one call' gives a clear use case, implying when the batch tool is preferred. It does not explicitly name alternatives like query_vulnerabilities for single-package use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_latest_advisoriesGet latest npm security advisoriesABrowse recently published, reviewed GitHub Security Advisories for the npm ecosystem. Filter by severity, vulnerability category (XSS, SQL/NoSQL Injection, SSRF, Access Control, Code Injection, etc.), an affected package name, or look up one exact advisory by GHSA or CVE ID. Paginated with an opaque cursor: pass a previous response's nextCursor back in as cursor to fetch the next page.
| Name | Required | Description | Default |
|---|---|---|---|
| cveId | No | Look up one exact advisory by its CVE ID (e.g. "CVE-2024-12345") | |
| cursor | No | Opaque pagination cursor from a previous response's nextCursor, to fetch the next page | |
| ghsaId | No | Look up one exact advisory by its GHSA ID (e.g. "GHSA-xxxx-xxxx-xxxx") | |
| affects | No | Filter to advisories affecting this npm package name | |
| category | No | Filter by vulnerability category. One of: access-control, dos, xss, ssrf, auth, code-injection, info-exposure, path-traversal, input-validation, prototype-pollution, command-injection, sqli, crypto, race-condition, open-redirect, csrf, crlf-injection, xml-injection, malicious-code, deserialization | |
| severity | No | Filter by severity (default all) | |
| direction | No | Sort by published date, newest or oldest first (default desc) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds valuable context about pagination using an opaque cursor and the need to pass nextCursor for subsequent pages, as well as the 'reviewed' status of advisories. These details go beyond the annotations and inform agent behavior.
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, front-loaded with the core purpose, followed by filtering options and pagination. Every sentence conveys 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?
Given the tool's moderate complexity (7 optional parameters, no output schema), the description adequately covers usage scenarios, filters, and pagination. It does not describe the response format in detail, but for a browsing/filtering tool this is acceptable. Context about 'reviewed' and 'recently published' helps set expectations.
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 restates the filter parameters (severity, category, package name, exact IDs) but does not add significantly new semantics beyond what the schema already provides. It does reinforce the cursor usage, but that is also in the schema 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 clearly states the tool browses recently published, reviewed GitHub Security Advisories for the npm ecosystem. It distinguishes from siblings by focusing on latest advisories with filtering and exact ID lookup, using specific verbs like 'browse', 'filter', and 'look up'.
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?
Provides clear context for using the tool: browsing latest advisories, filtering by severity/category/package, or looking up by GHSA/CVE ID. It implies when to use it (recent advisories) but does not explicitly contrast with sibling tools like query_vulnerabilities or batch_query_vulnerabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_packageGet npm package detailsAFetch npm registry metadata for a package: latest version, install scripts (preinstall/postinstall are a key risk signal), maintainers, license, and recent version history. Includes a link to the full npmscan.com analysis page.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact npm package name, e.g. "lodash" or "@scope/name" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, open-world, non-destructive behavior. The description adds context about what metadata is included and highlights install scripts as a risk signal, but it does not disclose additional behavioral traits like network calls, pagination, or potential limitations. This is acceptable given the annotation coverage, but not exceptionally rich.
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 sentences, front-loaded with the core action and a clear field list. No filler or redundancy, and the risk-signal note is valuable and concise.
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 one well-documented parameter and no output schema, the description sufficiently covers what the tool returns, provides a useful risk insight, and includes a link for deeper analysis. It does not explain error conditions or return formatting, but for a simple fetch tool with strong annotations, this is adequate.
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 parameter description is fully adequate, so baseline is 3. The description reinforces the package focus but does not add new parameter semantics beyond the 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 starts with a specific verb ('Fetch') and resource ('npm registry metadata'), listing concrete fields (latest version, install scripts, maintainers, license, version history). It clearly distinguishes from siblings like get_package_version by focusing on metadata rather than a specific version.
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 when to use it (when you need full package metadata, especially install scripts as a risk signal) and includes a link to an analysis page, giving context. However, it does not explicitly contrast with siblings like get_package_version or search_packages, nor does it state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_package_versionGet a specific npm package versionAFetch registry metadata for one exact version of a package (dependencies, install scripts, tarball). Use this to check a version pinned in a lockfile rather than the latest release.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact npm package name | |
| version | Yes | Exact version string, e.g. "4.17.21" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds behavioral context beyond annotations by detailing the returned metadata types (dependencies, install scripts, tarball) and the exact-version scope, which is not implicit in 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 core function and followed by a direct usage instruction. Every sentence earns its place, with no redundant or filler content.
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 simple read-only tool with two fully described parameters, no output schema, and good annotations, the description fully covers purpose, usage, and return contents. It is complete enough for an agent to select and invoke correctly without additional info.
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%: both 'name' and 'version' are documented with clear descriptions. The tool description does not add further parameter semantics, so the baseline of 3 is appropriate as the schema already provides full parameter meaning.
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 verb and resource: 'Fetch registry metadata for one exact version of a package'. It also lists specific contents (dependencies, install scripts, tarball) and distinguishes from siblings by emphasizing 'exact version' versus 'latest release', making it clear what makes this tool unique.
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 says 'Use this to check a version pinned in a lockfile rather than the latest release.' This gives a concrete use case and an exclusion, effectively guiding the agent to choose this tool over the likely alternative (get_package) for exact version lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_vulnerabilitiesQuery known vulnerabilities for a packageAQuery OSV.dev for known vulnerabilities affecting an npm package, optionally scoped to one version. Use before recommending or installing a package.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | npm package name | |
| version | No | Optional exact version to narrow results | |
| ecosystem | No | OSV ecosystem, default "npm" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds context that it queries an external service (OSV.dev) and targets known vulnerabilities, but does not disclose behavior like pagination, rate limits, or what happens when no vulnerabilities are found.
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 action, and contains no wasted words. It effectively conveys purpose and usage in a compact form.
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 simple query tool with full parameter documentation and safety annotations, the description is adequate. It omits explicit return format, but the tool's simplicity and prior context make it sufficiently 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 description coverage is 100%, with each parameter documented. The description adds marginal value by echoing 'npm package' and 'optionally scoped to one version,' but does not provide additional meaning beyond the 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 clearly states the tool queries OSV.dev for vulnerabilities affecting an npm package, optionally scoped to one version. It distinguishes itself from siblings by focusing on a single package query, though it doesn't explicitly name alternatives.
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 explicit guidance: 'Use before recommending or installing a package.' This gives clear context for when to use the tool, but does not mention exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_packagesSearch npm packagesASearch the npm registry by name or keywords. Returns matching packages with a link to their full npmscan.com risk/analysis page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default 20, max 50) | |
| query | Yes | Search text, e.g. a package name or keywords |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds value by specifying the return format (matching packages with a link to the npmscan.com risk/analysis page), which is useful beyond the annotations and does not contradict them.
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 concise sentences, front-loaded with the primary action. Every word adds value with no 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?
There is no output schema, so the description correctly explains the key return value (matching packages with a link). For a simple 2-parameter search tool with strong annotations, this is adequate, though it could briefly mention when to prefer get_package for exact matches.
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%, with both 'query' and 'limit' already documented in the input schema. The description's phrase 'by name or keywords' adds minimal new meaning over the schema's own 'e.g. a package name or keywords', so the baseline of 3 applies.
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 verb and resource: 'Search the npm registry by name or keywords.' It also explains the output (matching packages with a link), which differentiates it from the sibling get_package/get_package_version tools that target specific packages.
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 this tool is for searching by name/keywords, but it does not explicitly contrast it with alternatives like get_package for exact lookups. There is no 'when to use vs when not to use' guidance, so usage is implied rather than explicit.
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!