vaporcheck is an MCP server that verifies whether package names and file paths actually exist, preventing AI assistants from hallucinating or using fake identifiers. It provides a single verify_identifier tool with the following capabilities:
Verify Python packages (PyPI): Check if a Python package exists on PyPI before installing or recommending it, catching hallucinated or slop-squatted package names.
Verify JavaScript packages (npm): Check if an npm package exists before installing or recommending it.
Verify filesystem paths: Check if a file or directory path exists on the local machine before reading, editing, or referencing it. Supports relative paths via an optional cwd parameter.
Clear existence status: Returns one of four outcomes — exists, not-found, deprecated, or cannot-verify — so AI assistants can self-correct when an identifier doesn't exist.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@vaporcheck check if package 'reqeusts' exists on PyPI"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Stops AI coding assistants from using things that don't exist.
AI assistants sometimes invent package names, file paths, and function names that look real but aren't. Research found that almost 1 in 5 packages recommended by AI didn't exist — and attackers register those fake names to spread malware (this is called slopsquatting).
vaporcheck is a simple safety net: before your AI assistant installs a package or touches a file, it checks — does this actually exist? If not, it blocks the action and tells the assistant why, so it can correct itself.
AI: pip install reqeusts-slop-xyz ← a package that doesn't exist
⛔ BLOCKED by vaporcheck — that package was not found
AI: "Oops — I meant `requests`."
pip install requests ✅ goes through normallyReal packages and real files pass through instantly. You'll never notice vaporcheck until it saves you.
Related MCP server: npmguard
If you use Claude Code — two commands, done:
/plugin marketplace add cdmx-in/vaporcheck
/plugin install vaporcheck@cdmxThat installs both the protection (the blocker) and the verify_identifier tool your assistant can use to double-check things itself.
If you use any other AI tool that supports MCP:
pip install vaporcheckthen add this to your tool's MCP config:
{
"mcpServers": {
"vaporcheck": { "command": "vaporcheck-mcp" }
}
}Works on Windows, Mac, and Linux. No other dependencies.
Not sure it's working? Run python -m vaporcheck.doctor.
✅ Python packages (PyPI) — including whole requirements.txt files
✅ JavaScript packages (npm) — including package.json
✅ File paths on your computer
Coming next: more package ecosystems (Rust, Go, Ruby, Java) and code symbols.
Developers and the curious can find everything else — how it works, the research behind it — in docs/.
Check whether a model-emitted identifier actually EXISTS in its authoritative source, before you rely on it. Call this before recommending or installing a package, or before editing a file path, to catch hallucinated or slop-squatted identifiers. Returns exists / not-found / deprecated / cannot-verify.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | base dir for relative paths when kind=path | |
| kind | Yes | identifier class: pypi package, npm package, or filesystem path | |
| value | Yes | the identifier to verify (package name or path) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully shoulders the burden of behavioral disclosure. It clearly explains the tool checks existence in an authoritative source and lists the possible return values (exists, not-found, deprecated, cannot-verify), leaving no hidden assumptions.
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 main purpose, and every sentence adds value. No fluff or repetition. Highly efficient.
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 verification tool with three parameters and no output schema, the description covers the return values and usage context. It is missing potential notes on rate limits or side effects, but those are not critical for this tool. Overall sufficient and clear.
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 description coverage is 100%, so the baseline is 3. The description adds high-level context (e.g., 'authoritative source') but does not elaborate on individual parameters beyond what the schema already provides. This meets the baseline but does not exceed it.
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 ('check') and resource ('identifier') with a clear purpose ('exists in authoritative source'). It distinguishes the tool from general lookups by emphasizing hallucination/slop-squat detection, leaving no ambiguity about its role.
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 when to use the tool ('before recommending or installing a package, or before editing a file path') and why ('catch hallucinated or slop-squatted identifiers'). However, it does not explicitly state when not to use it or mention alternatives, which would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0verify_identifierScored across 1 tool
Only one tool exists, so there is no possibility of confusion between tools. The agent can reliably select the correct tool.
The single tool follows a clear verb_noun pattern (verify_identifier), which is consistent and predictable.
The server has only one tool, which is borderline thin for most use cases. While the tool's purpose is narrow, a more comprehensive server would likely need additional tools for related operations.
The server provides only a verification operation, lacking any CRUD or lifecycle tools for managing identifiers. This is a significant gap for any workflow beyond simple checks.
Blocks typosquatted or hallucinated npm/PyPI packages before an AI agent installs them.
check-package: block malicious npm/PyPI deps before your AI agent installs them. Free, no key.
Protects AI coding agents from installing malicious open source packages. Every npm and PyPI package is checked against SafeDep’s real-time threat intelligence before installation.
Pre-flight check for AI coding agents: hallucinated packages + secrets, 6 ecosystems, no account.
