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., "@Grype MCP Server Scan my project directory for vulnerabilities"
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.
Anchore MCP server for Grype vulnerability scanner
Integrate Grype vulnerability scanning directly into AI-assisted development workflows through the Model Context Protocol (MCP).
Install using uvx (recommended):
uvx grype-mcpOr using pipx:
pipx install grype-mcpOr using pip:
pip install grype-mcpAdd to your Claude Desktop configuration:
{
"mcpServers": {
"grype": {
"command": "uvx",
"args": ["grype-mcp"]
}
}
}For other MCP-compatible clients, add the server using:
Command: uvx
Args: ["grype-mcp"]
Start using Grype's vulnerability scanning capabilities!
Related MCP server: ScanRook MCP Server
The Grype MCP server provides these tools for AI assistants:
find_grype - Check if Grype is installed and get version info
update_grype - Install or update Grype to the latest version
get_db_info - Get vulnerability database status and version info
update_db - Update the vulnerability database
scan_dir - Scan project directories for vulnerabilities
scan_purl - Scan specific packages using PURL format (e.g., pkg:npm/lodash@4.17.20)
scan_image - Scan container images for vulnerabilities
search_vulns - Search the vulnerability database by CVE, package name, or CPE
get_vuln_details - Get detailed information about specific CVEs
Once configured, you can ask:
"Check if Grype is installed and up to date"
"Scan my project directory for vulnerabilities"
"Is pkg:npm/lodash@4.17.20 vulnerable?"
"Scan the nginx:latest Docker image"
"Search for Log4j vulnerabilities"
"Get details about CVE-2021-44228"
Python 3.10+
Grype (can be installed via the update_grype tool)
Docker (optional, for container image scanning)
The MCP server can help install Grype if it's not already available using the update_grype tool.
Directories - Scan entire projects with all their dependencies
Container Images - Docker images from any registry
Package URLs - Individual packages in PURL format
npm: pkg:npm/package@version
Python: pkg:pypi/package@version
Go: pkg:golang/package@version
Java: pkg:maven/group/artifact@version
And many more ecosystems
The MCP server acts as a bridge between AI assistants and Grype:
AI Assistant ↔ MCP Server ↔ Grype CLI ↔ Vulnerability DatabaseZero modifications to Grype required
Structured JSON responses optimized for AI consumption
Comprehensive error handling with helpful messages
Automatic tool management for easy setup
We welcome contributions! Please see:
CONTRIBUTING.md - Contribution guidelines
DEVELOPING.md - Development setup
CODE_OF_CONDUCT.md - Community standards
Licensed under the Apache License, Version 2.0. See LICENSE for details.
Grype - Vulnerability scanner for container images and filesystems
Syft - SBOM generation tool
Model Context Protocol - Open protocol for AI assistant integrations
Anchore Enterprise - Commercial SBOM-powered security platform
GitHub Issues - Bug reports and feature requests
Anchore Community Discourse - Community support and discussions
Documentation - Full documentation
Made with ❤️ by the Anchore team for the AI-assisted development community
Find the grype binary and check if it's installed.
Returns information about grype installation status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'returns information', leaving out details like whether it searches PATH, requires permissions, or has side effects. Minimal disclosure.
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 with no wasted words. Front-loaded with the action and followed by the outcome.
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 check tool with zero parameters and an output schema describing return info, the description is adequate. However, adding what 'installation status' includes (e.g., version, path) could enhance completeness.
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?
No parameters exist, and schema coverage is 100%. The description doesn't need to add param details, so baseline of 4 is appropriate.
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 finds the grype binary and checks installation status. It uses specific verb-resource pairing. However, it does not explicitly differentiate from sibling tools like 'update_grype', though the action is distinct enough.
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?
No guidance on when to use this tool versus alternatives. It simply describes what it does without context on appropriate scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the Grype vulnerability database.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It implies a read-only operation but does not specify any behavioral traits (e.g., network dependency, speed). For a simple info retrieval, this is adequate but not exemplary.
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?
One sentence, 11 words, front-loaded. Every word is necessary, no 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?
With no parameters and an output schema, the description is sufficient to understand the tool's purpose. However, it could briefly mention what kind of info (e.g., version, status) to be fully 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?
Tool has zero parameters, so schema coverage is trivially 100%. Description adds no parameter info, but baseline is 4 per instructions for 0 params.
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 'Get' and the resource 'information about the Grype vulnerability database'. This distinguishes it from siblings like get_vuln_details (specific vulnerabilities) and update_db (action).
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?
No explicit guidance on when to use vs alternatives. The description implies it for database info, but lacks direct comparison or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific vulnerability.
Args: cve_id: CVE identifier (e.g., CVE-2021-44228)
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral transparency. Only states 'Get detailed information' with no mention of authentication, rate limits, or data source freshness. Output schema exists but is not referenced.
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 purpose. The Args line is slightly redundant but does not waste space. Could omit the Args line and rely on schema.
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?
Simple single-param tool with output schema, so description is adequate. Missing any notes on error cases or expected behavior for malformed IDs, which would be helpful but not critical.
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 0%, so description must add meaning. Provides an example CVE ID format but does not explain accepted patterns beyond the example. The param name 'cve_id' already implies a CVE identifier.
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?
Description clearly states the verb 'Get' and resource 'detailed information about a specific vulnerability'. It implies uniqueness of CVE ID, distinguishing it from search_vulns which likely lists multiple vulnerabilities. However, no explicit differentiation from siblings.
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?
No guidance on when to use vs. alternatives. Implies use when a specific CVE ID is known, but no mention of scenarios where alternative tools like search_vulns are more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a directory for vulnerabilities using Grype.
Args: path: Path to the directory to scan include_dev: Include development dependencies
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| include_dev | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as side effects, permissions required, or the nature of the output. It only states it scans for vulnerabilities, which implies read-only but lacks explicit assurance.
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 short and to the point, with two sentences and a simple arg list. No unnecessary text, though it could be more structured for readability.
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 the existence of an output schema, the description does not need to detail return values, but it lacks context about prerequisites (e.g., path must exist) or error handling. It is adequate but not fully 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 0%, but the description adds basic meaning: 'path' is a directory, 'include_dev' includes development dependencies. However, it does not elaborate on the format or constraints, leaving some ambiguity.
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 scans a directory for vulnerabilities using Grype, with a specific verb and resource. It distinguishes from sibling tools like scan_image and scan_purl by targeting directories.
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?
No guidance on when to use this tool versus alternatives like scan_image or scan_purl. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a container image for vulnerabilities.
Args: image: Container image name/tag (e.g., nginx:latest, ubuntu:20.04)
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as whether the scan is read-only, requires network access, or has side effects. The term 'scan' implies safety but is not explicit.
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 extremely concise: one sentence for purpose followed by a structured Args block. No filler, every sentence serves a purpose.
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 one-parameter tool, the description covers the core functionality and parameter format. However, it lacks behavioral context (e.g., output description, safety) and is missing details that the output schema might provide.
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 0%, but the description includes an Args section that explains the 'image' parameter with format examples (e.g., nginx:latest), adding value beyond the schema's bare type 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 states 'Scan a container image for vulnerabilities' with a clear verb-resource pair. It distinguishes from siblings like scan_dir and scan_purl by specifying the target type (container image).
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?
Usage is implied by the name and description (for container images), but there is no explicit guidance on when to use this tool versus alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a specific package using PURL (Package URL) format.
Args: package_url: Package URL in PURL format (e.g., pkg:npm/lodash@4.17.20)
| Name | Required | Description | Default |
|---|---|---|---|
| package_url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'scan' without clarifying behavioral traits like whether it reads, modifies, or requires network access, or what side effects occur.
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 with front-loaded purpose. Every word earns its place, no fluff. The parameter description is integrated 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?
Given a single parameter and an output schema (assumed), the description covers core usage. However, it omits behavioral context (e.g., read-only) and typical usage scenarios, leaving some gaps for an agent unfamiliar with the domain.
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 0%, but the description adds a format constraint and an example for package_url. This adds meaningful context beyond the bare schema, helping the agent format the parameter correctly.
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 scans a specific package using PURL format, with a concrete example. This differentiates it from siblings like scan_dir or scan_image, which target directories or images.
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 no guidance on when to use this tool versus alternatives. No conditions, exclusions, or when-not-to-use hints are given, leaving the agent to infer based on package vs directory/image scanning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Grype database for vulnerability information.
Args: query: Search query (CVE ID, package name, etc.) search_type: Type of search: vuln, package, or cpe
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| search_type | No | vuln |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states it searches (implying read-only) but does not disclose behavioral details such as rate limits, permissions, or any side effects. The missing annotation coverage is not compensated.
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 short and front-loaded with the purpose. The Args section is clear and well-structured, though slightly technical. Every sentence serves a purpose.
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 the tool has 2 parameters and an output schema, the description provides adequate context for parameter usage. However, it lacks information on return values (though output schema may cover this) and overall behavior for a search tool.
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 description adds significant meaning beyond the input schema by explaining that query can be a CVE ID or package name, and search_type can be vuln, package, or cpe. This compensates for the 0% schema description 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 it searches the Grype database for vulnerability information with a specific verb and resource. It is distinguishable from sibling tools like get_vuln_details or find_grype, though not explicitly differentiated.
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 lists parameters but provides no guidance on when to use this tool versus alternatives like find_grype or scan_image. No context on prerequisites or exclusion criteria is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the Grype vulnerability database.
Args: force: Force update even if database is recent
| Name | Required | Description | Default |
|---|---|---|---|
| force | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral context. It only states 'Update' and explains the force param, but lacks details on network access, duration, or side effects. Minimal transparency.
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: one for purpose, one for parameter description. No fluff, front-loaded, every word earns its place.
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?
Output schema exists, so return values not required. For a simple mutation with one param, description is adequate but lacks behavioral and prerequisite context, which is a gap given no annotations.
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 has 0% description coverage, but description explains force as 'Force update even if database is recent,' adding meaning beyond the schema's type and title. Only one parameter, well described.
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 states 'Update the Grype vulnerability database,' which clearly identifies the action and resource. It distinguishes from sibling tool update_grype (likely updates the tool itself), but does not explicitly differentiate.
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?
No guidance on when to use this tool versus alternatives like update_grype or when a database update is necessary. The force parameter is described but not contextualized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install or update the grype binary to the latest version.
Downloads and installs grype using the official Anchore installer.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions installing/updating the binary but lacks details on system impact, required permissions, version checking, or side effects like overwriting existing binaries. This is insufficient for a tool that modifies the system.
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 long, front-loaded with the core action, and contains no extraneous information. Every word earns its place.
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 no annotations and no parameters, the description covers the basic action but omits behavioral context like success/failure behavior, system impact, or prerequisites. An output schema exists but its contents are unknown; still, overall completeness is adequate but not fully informative.
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 has zero parameters, so the description does not need to elaborate on parameter semantics. Baseline for 0 params is 4, and the description adequately explains the action without needing param details.
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 'install or update', the resource 'grype binary', and the scope 'to the latest version', making the purpose unambiguous. It also distinguishes from sibling tools like scan_image or update_db.
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 usage for getting the latest grype via the official installer, but it does not explicitly state when to use this tool versus alternatives like update_db (which updates the database) or find_grype (which locates the binary). No when-not guidance provided.
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.4.0find_grypeget_db_infoget_vuln_detailsscan_dirscan_imagescan_purlsearch_vulnsupdate_dbupdate_grypeScored across 9 tools
Each tool has a clearly distinct purpose: installation check, DB info, vulnerability details, three scan types (directory, image, PURL), search, and two update operations. No overlap.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., find_grype, scan_dir, update_db), making them predictable and easy to use.
9 tools is well-scoped for a vulnerability scanning server: covering installation, scanning, searching, and updates without unnecessary bloat or missing essentials.
Covers core workflows: installation check, DB info, scanning (directory, image, PURL), vulnerability details, search, and updates. Minor gaps like returning raw scan results or listing installed packages, but not critical.
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
Generate SBOMs, scan vulnerabilities, and analyze dependencies from local projects or Git repos.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
