Skip to main content
Glama

Get latest npm security advisories

get_latest_advisories
Read-only

Browse 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cveIdNoLook up one exact advisory by its CVE ID (e.g. "CVE-2024-12345")
cursorNoOpaque pagination cursor from a previous response's nextCursor, to fetch the next page
ghsaIdNoLook up one exact advisory by its GHSA ID (e.g. "GHSA-xxxx-xxxx-xxxx")
affectsNoFilter to advisories affecting this npm package name
categoryNoFilter 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
severityNoFilter by severity (default all)
directionNoSort by published date, newest or oldest first (default desc)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
categoryYes
severityYes
directionYes
advisoriesYes
nextCursorYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark this as read-only and non-destructive, and the description adds useful behavioral context beyond that: it notes advisories are 'reviewed,' explains the opaque cursor pagination mechanism, and clarifies that nextCursor is passed back as cursor. This gives the agent a practical model of how the tool behaves.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no filler: the main action is front-loaded, the filtering options are compactly enumerated, and pagination is explained in a single clear sentence. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only query tool with an output schema and fully described parameters, the description covers all major behaviors: browsing, filtering by severity/category/package, exact ID lookup, and pagination. Nothing needed for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter. The description restates filter dimensions and the pagination flow but does not add substantive new meaning beyond what the schema provides. It meets the baseline without compensating for any schema gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Browse recently published, reviewed GitHub Security Advisories for the npm ecosystem.' It clearly distinguishes this tool from generic vulnerability queries or individual package lookups by scoping to npm security advisories. The stated filtering and exact-lookup capabilities make its role unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool by listing its capabilities, but it never explicitly contrasts it with siblings like get_cve or query_vulnerabilities, nor states when to prefer one of those instead. The usage context is inferable but not spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation4/5

Each tool targets a distinct workflow—install script analysis, transitive dependency resolution, batch OSV queries, provenance verification, CVE lookup, advisory browsing, package metadata, exact-version checks, single-package vuln checks, and search. The only mild overlap is that several get_/query_ tools return vulnerability data, but the descriptions clearly delineate when to use each.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: get_package, query_vulnerabilities, analyze_transitive_dependencies, check_package_provenance, etc. There are no mixed casing styles or vague verbs, making the set highly predictable.

Tool Count5/5

10 tools is well-scoped for an npm security scanning server. Each tool earns its place by covering a distinct facet of the domain without redundancy or bloat.

Completeness4/5

The surface covers package discovery, metadata, exact-version vulnerability checks, batch scanning, transitive graph analysis, install-script heuristics, provenance, advisories, and CVE enrichment. Minor gaps remain—e.g. no full tarball code review and maintainer-history red flags are explicitly out of scope—but core agent workflows are covered.

Resources