Click on "Install 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., "@PatchPilot MCP Check if lodash@4.17.0 is safe"
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.
Security scanner for vibe coders. Checks npm packages for known vulnerabilities before you install them.
PatchPilot is an MCP server that integrates with Claude Code, Cursor, and other AI coding tools. When you're about to install a package, you can ask Claude to check if it's safe first.
Example:
You: "Check if lodash@4.17.0 is safe to use"
Claude: 🚨 lodash@4.17.0 has 4 known vulnerabilities!
...
💡 Recommendation: Update to lodash@4.17.21 or laterRelated MCP server: agent-security-scanner-mcp
Node.js 18+
Claude Code or another MCP-compatible client
Clone this repository:
git clone https://github.com/YOUR_USERNAME/patchpilot-mcp.git
cd patchpilot-mcpInstall dependencies:
npm installBuild:
npm run buildAdd to your Claude Code config (~/.claude/settings.json):
{
"mcpServers": {
"patchpilot": {
"command": "node",
"args": ["/path/to/patchpilot-mcp/dist/index.js"]
}
}
}Or for development (without building):
{
"mcpServers": {
"patchpilot": {
"command": "npx",
"args": ["tsx", "/path/to/patchpilot-mcp/src/index.ts"]
}
}
}Restart Claude Code after adding the config.
Once installed, ask Claude to check packages:
"Check if express@4.17.0 is safe"
"Is next@14.1.0 secure?"
"Check lodash 4.17.0 for vulnerabilities"
PatchPilot uses the OSV API (Google's Open Source Vulnerabilities database) to check packages. The API is:
Free (no API key needed)
Fast
Comprehensive (aggregates data from npm, GitHub, NVD, and more)
check_packageCheck a single npm package for known vulnerabilities.
Input:
name: Package name (e.g., "lodash")
version: Package version (e.g., "4.17.0")
Output:
Vulnerability count and severity breakdown
Details of each vulnerability
Recommended fix version
MIT
Check if an npm package has known security vulnerabilities. Use this before installing any package to ensure it is safe.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name (e.g., "lodash", "next", "express") | |
| version | Yes | Package version (e.g., "4.17.0", "14.1.0") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It does not explain how the check works (e.g., whether it queries a vulnerability database, requires network access), what side effects it has, or what the response looks like. This leaves significant uncertainty for the agent.
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 only two sentences: the first states the purpose, the second provides a usage guideline. It is front-loaded, efficient, and contains no 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 there is no output schema, the description should explain what the tool returns (e.g., a list of vulnerabilities, a boolean indicator). It also does not mention whether the check covers transitive dependencies or what constitutes 'safe.' These gaps make it incomplete for a tool with no structured output metadata.
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 describes both parameters (name and version) with examples. The description adds no additional parameter details, so it earns the baseline for tools with 100% 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's purpose: 'Check if an npm package has known security vulnerabilities.' It uses a specific verb ('check') and resource ('npm package'), making it unambiguous even without sibling tools for comparison.
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 provides explicit when-to-use guidance: 'Use this before installing any package to ensure it is safe.' It does not mention alternatives or exclusions, but the context is clear and actionable.
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. Dates show when Glama detected each change.
v0.1.0check_packageOnly one tool exists, so there is no possibility of confusing it with other tools. The tool's purpose is clearly and unambiguously defined.
With a single tool, naming consistency is trivially satisfied. The name 'check_package' follows a clear verb_noun style that would be consistent if extended.
The server has only one tool, which feels too thin for the implied scope of 'PatchPilot'—a name suggesting broader patching and management workflows. One tool is insufficient to provide a meaningful set of operations.
The tool only checks for the presence of known vulnerabilities but provides no ability to list details, assess multiple packages at once, or suggest remediation. This creates significant gaps for agents needing comprehensive security information.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provide AI-powered real-time analysis and intelligence on NPM packages, including security, depend…
check-package: block malicious npm/PyPI deps before your AI agent installs them. Free, no key.
Deep security scans of repos you own from your editor: dependency CVEs, SAST, git-history secrets.
Detect malicious or vulnerable npm packages: registry search, OSV.dev and GitHub advisory lookups
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ProduktEntdecker/patchpilot-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server