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 the most recently published, reviewed GitHub Security Advisories for the npm ecosystem, optionally filtered by severity.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| severity | No | Filter by severity (default all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds context about 'recently published, reviewed' advisories, but does not disclose additional behavioral traits like rate limits or authentication needs. No contradiction 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?
The description is a single, direct sentence that leads with the action and contains no filler. It is appropriately sized for the tool's simplicity.
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 listing tool with two optional, fully documented parameters, the description is complete enough. It states what the tool returns, the ecosystem, the temporal scope, and the optional filter. No output schema is necessary for this list-browsing 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 input schema fully documents both parameters (page with range/default, severity with enum/default), so the description does not need to repeat those details. It does mention optional severity filtering, aligning with the schema, but adds little new semantic value beyond the structured definition.
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 identifies the action ('browse') and the resource ('most recently published, reviewed GitHub Security Advisories for the npm ecosystem') and mentions the severity filter. It distinguishes this from sibling query tools by emphasizing 'latest' advisories.
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 gives clear context for when to use it: to browse recent npm advisories, optionally filtered by severity. It does not explicitly name alternatives or exclusions, but the phrase 'most recently published' implies this is for latest listings rather than targeted searching.
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!