Skip to main content
Glama
ozturkaburak

Snyk MCP Server

by ozturkaburak

Snyk MCP Server

License: MIT TypeScript MCP

A Model Context Protocol (MCP) server that integrates Snyk security scanning with Claude Code and other MCP clients.

Features

  • šŸ” List all Snyk projects in your organization

  • šŸ› Query security issues by severity (critical, high, medium, low)

  • šŸŽÆ Filter issues by project name or ID

  • šŸ”§ Scope filtering (Frontend/Backend)

  • šŸ“Š Get normalized issue data with CVEs, dependencies, and fix information

Related MCP server: Snyk MCP REST

Prerequisites

  • Node.js 18+

  • A Snyk account with API access

  • Snyk organization ID

Installation

  1. Clone the repository:

git clone https://github.com/ozturkaburak/snyk-mcp-server.git
cd snyk-mcp-server
  1. Install dependencies:

npm install
  1. Create .env file from template:

cp .env.example .env
  1. Configure your Snyk credentials in .env:

SNYK_TOKEN=your_snyk_token_here
SNYK_ORG_ID=your-org-id_here

Usage

Build the project

npm run build

Run in production mode

npm start

Run in development mode

npm run dev

MCP Tools

This server provides three MCP tools:

1. list_snyk_projects

Lists all projects in your Snyk organization.

Parameters: None

Example:

list_snyk_projects()

2. get_project_issues

Get all issues for a specific project.

Parameters:

  • projectId (required): The Snyk project ID

  • severity (optional): Filter by severity - "critical", "high", "medium", or "low"

Example:

get_project_issues({
  projectId: "abc-123-def-456",
  severity: "critical"
})

3. get_snyk_issues

Get issues across multiple projects with advanced filtering.

Parameters:

  • projectIds (optional): Array of project IDs

  • projectNames (optional): Array of project names (fuzzy matching)

  • severity (optional): Filter by severity

  • scope (optional): "FE" (Frontend), "BE" (Backend), or "UNKNOWN"

Examples:

// Get all critical backend issues across multiple microservices
get_snyk_issues({
  projectNames: [
    "api-gateway",
    "auth-service",
    "payment-service",
    "user-service",
    "notification-service"
  ],
  severity: "critical",
  scope: "BE"
})

// Get high severity frontend issues
get_snyk_issues({
  projectNames: ["web-app", "mobile-app"],
  severity: "high",
  scope: "FE"
})

// Get all critical issues without filtering by project
get_snyk_issues({
  severity: "critical"
})

Integration with Claude Code

Add this to your Claude Code MCP settings (.claude/mcp_settings.json):

{
  "mcpServers": {
    "snyk-local": {
      "command": "node",
      "args": ["/path/to/snyk-mcp-server/dist/index.js"],
      "env": {
        "SNYK_TOKEN": "your-snyk-token",
        "SNYK_ORG_ID": "your-org-id"
      }
    }
  }
}

Configuration

The server uses environment variables for configuration:

Variable

Description

Required

SNYK_TOKEN

Your Snyk API token

Yes

SNYK_ORG_ID

Your Snyk organization ID

Yes

Getting Your Credentials

  1. SNYK_TOKEN: Get from Snyk Account Settings

  2. SNYK_ORG_ID: Find in your org settings URL: https://app.snyk.io/org/your-org-id/manage/settings

Project Structure

snyk-mcp-server/
ā”œā”€ā”€ src/
│   ā”œā”€ā”€ index.ts      # MCP server implementation
│   ā”œā”€ā”€ snyk.ts       # Snyk API client
│   └── types.ts      # TypeScript type definitions
ā”œā”€ā”€ dist/             # Compiled JavaScript
ā”œā”€ā”€ .env.example      # Environment template
└── package.json

Development

TypeScript Development

npm run dev

Building

npm run build

API Documentation

See API_DOCUMENTATION.md for detailed Snyk REST API documentation.

Troubleshooting

Common Issues

"SNYK_TOKEN not set"

  • Make sure you created .env file with your token

"No projects found"

  • Verify your SNYK_ORG_ID is correct

  • Check your token has access to the organization

"Critical issues not showing"

  • Some issues may not be synced to REST API yet

  • Check the issue in Snyk UI to verify it exists

  • See FINDINGS_REPORT.md for analysis

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

License

MIT License - see the LICENSE file for details.

Author

Built with ā¤ļø for secure software development

Available Tools

3 tools
get_project_issuesD
ParametersJSON Schema
NameRequiredDescriptionDefault
scopeNo
severityNo
projectNameYes

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_snyk_issuesD
ParametersJSON Schema
NameRequiredDescriptionDefault
scopeNo
severityNo
projectIdsNo
projectNamesNo

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_snyk_projectsD
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv1.0.0
    • First observedget_project_issues
    • First observedget_snyk_issues
    • First observedlist_snyk_projects

TDQS

D1.5/5.0

Scored across 3 tools

Disambiguation2/5

The names 'get_project_issues' and 'get_snyk_issues' are very similar and lack descriptions, making it difficult for an agent to distinguish them. 'list_snyk_projects' is distinct, but the overlap between the first two harms clarity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (get_project_issues, get_snyk_issues, list_snyk_projects), demonstrating strong naming consistency.

Tool Count3/5

With only 3 tools, the server feels minimal for a security-focused service, but it may represent a focused subset. The count is borderline but not extreme.

Completeness1/5

Based on the tool names, the server only provides some 'get' and 'list' operations. Missing critical actions like creating, updating, or deleting projects or issues, leading to severe incompleteness for a typical security workflow.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    B
    quality
    D
    maintenance
    Allows developers to query security findings (SAST issues, secrets, patches) using natural language within AI-assisted tools like Claude Desktop, Cursor, and other MCP-compatible environments.
    17
    9
    MIT
  • A
    license
    Not graded
    quality
    F
    maintenance
    Provides security scanning capabilities through Snyk CLI tools and REST API, enabling AI assistants to test projects for vulnerabilities, retrieve security issues, and manage Snyk projects with comprehensive SAST, container, and infrastructure as code scanning.
    2
    MIT
  • F
    license
    Not graded
    quality
    Not graded
    maintenance
    An MCP server that provides Claude Code with access to Black Duck SCA for managing vulnerabilities, licenses, and policy violations through natural language. It enables users to query component risks and execute Black Duck Detect scans directly within their workspace.
    -
  • A
    license
    Not graded
    quality
    D
    maintenance
    Security scanning MCP server that connects Claude to RepoMend findings, enabling vulnerability management and automated fix drafting.
    MIT