vulnerable.now

Check dependencies, SBOMs and website technologies

check_stack

Read-onlyIdempotent

Find known vulnerabilities in what a project or site runs, ranked by what to fix first. Send exact package versions, the raw content of a lockfile (package-lock.json, poetry.lock, go.sum and others), a CycloneDX or SPDX SBOM, a Wappalyzer export, or detected technologies such as nginx 1.18.0. Returns each finding with severity, exploitation, priority and fixed versions.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_stack"
  }
}

Input Schema

Name	Required	Description
`file`	No	A whole file: a lockfile (recognized by its name), a CycloneDX or SPDX SBOM, or a Wappalyzer JSON or CSV export. Up to 5 MB.
`packages`	No
`technologies`	No	Website technologies, as Wappalyzer or a person names them.

Output Schema

Name	Required	Description
`error`	No
`results`	No
`complete`	No
`packages`	No
`checkedAt`	No
`fix_first`	No	Up to 10 findings, most urgent first.
`vulnerable`	No
`technologies`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds ranking semantics ('ranked by what to fix first') and finding fields, but since an output schema exists those details largely duplicate structured data, and it says nothing about rate limits, behavior on unrecognized packages, or partial failures.

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?

Two dense sentences with the outcome front-loaded and the accepted inputs immediately after. No filler, no restatement of the title, and every clause carries information the agent needs.

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

Completeness4/5

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

Given an output schema and rich annotations, the description covers what an agent needs: accepted input formats, the exact-version constraint, and the ranked result shape. The one gap is that all three parameters are optional, and the description only implies via 'or' that at least one input must be supplied.

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

Parameters4/5

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

Schema coverage is 67%, and the description usefully ties parameter intent to concrete examples: whole-file content in recognized formats (package-lock.json, poetry.lock, go.sum), exact versions rather than ranges, and technology names like nginx 1.18.0. It doesn't clarify whether the three inputs can be combined in one call, which is the remaining ambiguity.

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?

States a specific verb and resource ('Find known vulnerabilities in what a project or site runs') plus the ranking behavior, and the described inputs (lockfiles, SBOMs, Wappalyzer exports, technologies) make it unmistakable versus siblings like get_vulnerability or get_package, which operate on single items.

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

Usage Guidelines4/5

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

The second sentence gives concrete invocation guidance by enumerating the accepted input shapes — exact package versions, raw lockfile content, CycloneDX/SPDX SBOMs, Wappalyzer exports, detected technologies. It does not say when to prefer this over alternatives such as get_package for a single lookup, so it stops short of full routing guidance.

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

All vulnerable.now tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?